Alex,
What's the story with the new version? Has it been released?
What's the story with the new version? Has it been released?
Sep 30, 1999, 6:36 AM
Administrator (9387 posts)
Sep 30, 1999, 6:36 AM
Post #2 of 8
Views: 2866
Sorry, it seems like the email missed a few people. If anyone hasn't gotten an email notification, send me an email and I'll send you download instructions.
Cheers,
Alex
Cheers,
Alex
Oct 1, 1999, 7:49 AM
Novice (39 posts)
Oct 1, 1999, 7:49 AM
Post #3 of 8
Views: 2881
I hope the new version searches like Yahoo.
I also haven't received the new version, check you database Alex, it looks that a lot of people is not receiving the new version.
I also haven't received the new version, check you database Alex, it looks that a lot of people is not receiving the new version.
Oct 1, 1999, 8:31 AM
Veteran / Moderator (6956 posts)
Oct 1, 1999, 8:31 AM
Post #4 of 8
Views: 2890
The new version has some significant improvements.
One of the understated ones is that the 'category' listing has moved closer to template based, and columns are built in. (Though there seems to be a bug with a single column, and it's better to comment out the line in HTML_templates.pm).
Alex has put a lot into this, and it will evolve rapidly, I'm sure.
Hopefully, we'll see interim releases, and most importantly an 'upgrade' script. It's relatively easy to import the links 2.0 data, but I had a hell of a time importing my LinkSQL data into the new tables... Since MySQL supports 'alter' I ended up copying the database and altering the old one to fit the new format.
Alex will have to take a little time out to write down some procedures (docs) on these new features.
HOpefully, people will keep posting on what they find, so that until some official documentation is developed, we have a collaborative on-line one in development.
One of the understated ones is that the 'category' listing has moved closer to template based, and columns are built in. (Though there seems to be a bug with a single column, and it's better to comment out the line in HTML_templates.pm).
Alex has put a lot into this, and it will evolve rapidly, I'm sure.
Hopefully, we'll see interim releases, and most importantly an 'upgrade' script. It's relatively easy to import the links 2.0 data, but I had a hell of a time importing my LinkSQL data into the new tables... Since MySQL supports 'alter' I ended up copying the database and altering the old one to fit the new format.
Alex will have to take a little time out to write down some procedures (docs) on these new features.
HOpefully, people will keep posting on what they find, so that until some official documentation is developed, we have a collaborative on-line one in development.
Oct 1, 1999, 1:00 PM
Novice (39 posts)
Oct 1, 1999, 1:00 PM
Post #5 of 8
Views: 2883
Well, it looks that all have received the new version, except for me.
Maybe Alex don't want to send me the new version because it still searches very poor, and that feature is the only one that I need.
If Alex can't make a better search engine, I will have to use the PHP3 version I have found, the only thing I don't know is what is going to happen to my money.
Maybe Alex don't want to send me the new version because it still searches very poor, and that feature is the only one that I need.
If Alex can't make a better search engine, I will have to use the PHP3 version I have found, the only thing I don't know is what is going to happen to my money.
Oct 1, 1999, 5:44 PM
Veteran / Moderator (6956 posts)
Oct 1, 1999, 5:44 PM
Post #6 of 8
Views: 2875
You will find that if the only think you find at fault with LinkSQL is that it can't search like the mulit-million dollar software behind Yahoo, you will be very disappointed with the performance of PHP as your driving force.
It has a place, in scripting dynamic pages on the server (rather than client-side javascript), but for managing a site, it has limitations that are not found with other cgi programs.
One of the problems I have found is because the code is embeded in the HTML, it's processed each time the page/frame is accessed, and that creates some odd behaviour with the <back> and <forward> buttons on the browser. Page caching doesn't work quite right, and can give the users some very odd -- or problematic -- results (especially where information is being sent TO the server).
Phrase searching is partially enabled in this release, and it's on the list of things Alex has been working on for awhile.
If that's what you mean by 'yahoo type' searches, then when the foreign character support for searches is finalized, this type of search will be too.
In thinking about my own use of the net, the number of times I search for "word1 word2" as a phrase, vs "word1 word2" as an AND or OR is very, very small -- usually where I want to exclude a term and would use a 'NOT' if the option was offered.
It took 7 seconds to index my 425 link test database. (Some of the entries are 15k of text in size.) I imagine it would take roughly as long (maybe a bit less) to just SEARCH and RETURN a full-text search on that database. Multiply this over a larger database, more simultaneous searches, etc, and the processing load becomes extreme, and puts you back in the same (perhaps worse) position of resource consumption that Links 2.0 had. (the other benefits on database size, etc, are still greater with SQL).
Yahoo gains much of its speed (forgetting its top-end investment in hardware and software) in that many searches are already processed, cached, and just regurgitated. Diskspace (and even ram) is cheaper than CPU).
It defeats most of the benefits gained by SQL and Indexed access.
Weighted searches, with the ability to weight certain fields higher than others, to create more 'relevance' in the searches returned, is a much better, and more desirable feature -- and it exists. This puts the entries that more closely fit the criteria at the top, while still allowing the searches to include fields that often return useless 'hits' such as email address and URL.
(BTW... the changes I posted for the last version apply to the 1.1beta as well.)
I _would_ like to see more ability to use SQL-type commands in the search dialogs, and the admin interface fixed up to look more like the user search -- so that AND/OR and EXACT/SUBSTRING are options, and an SQL pass-through for returning links that match a generic SQL query for maintennance reasons.
Full-text searching ("like yahoo") is coming, I just don't see it being a benefit, and do see it as defeating much of the benefits of an Indexed RDBMS.
It has a place, in scripting dynamic pages on the server (rather than client-side javascript), but for managing a site, it has limitations that are not found with other cgi programs.
One of the problems I have found is because the code is embeded in the HTML, it's processed each time the page/frame is accessed, and that creates some odd behaviour with the <back> and <forward> buttons on the browser. Page caching doesn't work quite right, and can give the users some very odd -- or problematic -- results (especially where information is being sent TO the server).
Phrase searching is partially enabled in this release, and it's on the list of things Alex has been working on for awhile.
If that's what you mean by 'yahoo type' searches, then when the foreign character support for searches is finalized, this type of search will be too.
In thinking about my own use of the net, the number of times I search for "word1 word2" as a phrase, vs "word1 word2" as an AND or OR is very, very small -- usually where I want to exclude a term and would use a 'NOT' if the option was offered.
It took 7 seconds to index my 425 link test database. (Some of the entries are 15k of text in size.) I imagine it would take roughly as long (maybe a bit less) to just SEARCH and RETURN a full-text search on that database. Multiply this over a larger database, more simultaneous searches, etc, and the processing load becomes extreme, and puts you back in the same (perhaps worse) position of resource consumption that Links 2.0 had. (the other benefits on database size, etc, are still greater with SQL).
Yahoo gains much of its speed (forgetting its top-end investment in hardware and software) in that many searches are already processed, cached, and just regurgitated. Diskspace (and even ram) is cheaper than CPU).
It defeats most of the benefits gained by SQL and Indexed access.
Weighted searches, with the ability to weight certain fields higher than others, to create more 'relevance' in the searches returned, is a much better, and more desirable feature -- and it exists. This puts the entries that more closely fit the criteria at the top, while still allowing the searches to include fields that often return useless 'hits' such as email address and URL.
(BTW... the changes I posted for the last version apply to the 1.1beta as well.)
I _would_ like to see more ability to use SQL-type commands in the search dialogs, and the admin interface fixed up to look more like the user search -- so that AND/OR and EXACT/SUBSTRING are options, and an SQL pass-through for returning links that match a generic SQL query for maintennance reasons.
Full-text searching ("like yahoo") is coming, I just don't see it being a benefit, and do see it as defeating much of the benefits of an Indexed RDBMS.
Oct 2, 1999, 8:53 AM
Administrator (9387 posts)
Oct 2, 1999, 8:53 AM
Post #7 of 8
Views: 2881
SuperSearch: If you still haven't received the download instructions, please send me an email.
As for searching, we are working on a new search module that will be a huge improvement on the current indexing scheme. It's about two to three weeks away from completion though. It will allow really easy access to the index, and will hopefully support Altavista style syntax of +, -, and phrases, although how complete is still to be determined. We have been using the complete Dmoz as a benchmark, and are still getting search results in < 2 seconds, sometimes under 1.
Cheers,
Alex
As for searching, we are working on a new search module that will be a huge improvement on the current indexing scheme. It's about two to three weeks away from completion though. It will allow really easy access to the index, and will hopefully support Altavista style syntax of +, -, and phrases, although how complete is still to be determined. We have been using the complete Dmoz as a benchmark, and are still getting search results in < 2 seconds, sometimes under 1.
Cheers,
Alex