I’ll try to answer these inline below.
On Apr 8, 2010, at 5:06 AM, Thomas Kimmich wrote:
Hi Walter and all,
anyway, I´d like to keep the thread warm and it`s no accident that I
chose the “OFF TOPIC” for it.
So let me resume:
Using Actions:
only for static sites, that requires the update by changing content
in freeway and will do so by uploading? Not too bad, but 99% of (my)
pages will be the more or less dynamic using webyep. Believe me - I
´m not really waiting for an action, `cause the updating will be
"the beer of my customers (as it´s free said in germany)
Yes, the Action method would not work for any of the dynamic parts,
only for the static things that Freeway can “see” while publishing.
Sphider Search Engine:
Nice engine with a small backend, where I could say to my customer:
"If you change content, please make sure to reindex your Search
Engine. In Sphider it´s one click away and thats the reason why I could love it. The only problem in here is, that some "providers" not allow to index their own hosts. The workaround over the own plattform seems to be not suitable for my customers - isnt it?
Hosting often turns up as the elephant in the living room (amusing
english-language saying, might be American, but I’m not sure). For
example, I can’t count the number of problems people have doing what I
consider to be the most basic things on the (still popular for some
reason, must be the page 3-style commercials) GoDaddy service.
Sphider is a very very nice system, and ideally suited to a mixture of
static and dynamic content. If you can guide your customers to a
hosting provider that actually works, then you can implement it.
So Walter - to my opinion not the actionizing will solve the
problems - but small apps can do this for sure. Could you or someone
else point some other small solutions that´s worth to have a look on?
In another thread I remember you said something like:
It`s not too difficult to write a search engine if a mySQL is
available - just 20 lines of code or something like that. What
could we expect of a solution like that?
The problem with this statement is that it presumes that all of your
content lives in the database, or that you have a “crawler” like
Sphider’s that indexes the static content periodically and stores it
in the database. MySQL includes some very nice search engine functions
as a part of its flavor of the SQL language standard. (Ranking, stop
words, a rudimentary proximity feature, boolean operators, etc.)
The devil there is in the details. If you are using a content
management system or a crawler, if the search engine has to
“normalize” the content (by stripping out all the extraneous HTML
fluff that surrounds the actual content) then it also has to make some
qualitative decisions about that content. What value should it place
on the document’s title, meta tags, H1 tag, etc. In the case of a
normal layer-based Freeway layout, content order is not a predictor of
importance or even logical flow. The first paragraph you see on the
page could very easily be located near the end of the HTML source, and
the search engine cannot see that.
Any of the search engines I have written myself have been centered
around a document model that I could control: usually the content was
fully separated from the presentation, so I had nice logical blocks of
plain text to search – any styling was added separately when that
content was filtered through the application, so I didn’t have to step
around that in order to find the actual content in the midst of a lot
of HTML “noise”.
A search engine can also be extremely naive. For example, here’s a SQL
query that will find the word “oranges”:
SELECT * FROM `content` WHERE `plain_text` LIKE '%oranges%';
This query will not find the word “orange”, though. For that, you need
to perform an operation called “stemming”, where plurals are reduced
to their singular equivalents, complex words are broken down into
their components and then searched for individually, etc. None of this
would fit into the mythical 20 lines of code.
Further, none of this gets you the quality of search that you would
from something like Sphinx or Solr, two open-source search engines I
have used in the past. Those engines give you ranked results, and you
can weight the results based on any parameter you choose, or perform
boolean queries and other more exacting techniques to refine the
results. They are also considerably faster for large content sets.
I´d like to say: The one should deliver the backend, I would deliver
the graphics, put it together to a small own app, maybe shared for a
few bucks to defray development costs - and that`s it. Or is this
too optimistic?
Not at all, it just depends on where you set your expectations. If you
want something that does a “good-enough” job of searching for average-
sized sites, but doesn’t set itself up to be the next Google, then
yes, it’s quite possible. But if you create something like this, for
money or for free, I can tell you with certainty that you will need to
support it for the rest of its life, and it can become a full-time job
to explain it to the end users.
Walter
offtopic mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options
