In the past week, I've been digging into LinkSQL and SQL in general.

While links 2.0 is quite impressive, and people have done awesome mods with it, putting an SQL database behind it moves it several orders of magnitude beyond.

I'm really impressed with what can be done with SQL and how easy it's made things that have previously been quite difficult, or even impossible.

By using tables to hold data, MySQL does most of the work, and the SQL language does most of the rest.

There is new book out, (I finally found it in Barnes and Nobles) "MySQL and mSQL" pub: O'reilly. It was worth the wait. It's answering all the little questions that I've had, including security issues.

I'm curious as to how many people are using LinkSQL and visiting here, and how many of those are making mods, or looking for mods?

Alex: Still hoping you come up with the few mods you had been working on and been asked for. I'll post an updated wish-list to the old thread

pugdog,

I purchased Links-SQL a few weeks ago, but it seemed that only the most basic mods were available, so I decided to wait for it to mature.

At the time, I had the most concern about adding fields, but it appears Alex has addressed that.

My second-most concern had to do with the handling of the Multi-Cat Mod. I am still a little disconcerted with the prospect of having to keep a list of ID numbers handy in order to set up links in multiple categories (my project will go well over 1000 cats). However, this is a problem in Links2 as well.

I have another item, but it fits better under your "wishlist," so I'll post it there.

Bob

[This message has been edited by bjordan (edited August 28, 1999).]

I purchased it shortly after it was released, and have been running it "hidden" in tandem to my links 2.0 site, waiting till I can get the two close enough.

Really, all I _need_ is the 3-level-new/updated mod to go live. I have not done it, since I know Alex is working on it, and I'd rather have the official version, for compatibility reasons.

I've figured enough out that I've added fields, tables, the search logger, and more to my version. I'll probably go live this week with it, one way or another.

Because of the mods I've made, I've set up another site with just the standard 'text' links (since my site is all internal image links).

I'm not sure what you mean by "multi-categories"....

If you want your links to show up in different categories, just go to the modify screen for that link, and click "alternate". You can add that link to as many categories as you'd like.

Right now it's an admin-only feature, it seems, but it might be able to be generalized with a select type box for users to add. Though, for spam reasons you'd like to limit users to 3 categories or less most likely, and you'd really like the description to be tailored to each specific location.....

Hello Mr. Pataki!


This I will try to debate further on this thread...

www.gossamer-threads.com/scripts/forum/resources/Forum9/HTML/000081.html

For those of you who are interested in saving some money and time, www.amazon.com is a good alternative to buy it from there!




[This message has been edited by rajani (edited August 29, 1999).]

pugdog,

I was referencing Loopy's Multi-Categorie mod www.online-sweepstakes.com/links-mods/ --which I believe Alex integrated into Links-SQL. (I know that you are familiar with all this, but I'll mention it here for those that may not be.)
In Links2, the Multi-Cat mod generates a drop-down in the admin screen. If you have hundreds of categories, the drop-down can get so large that it cripples the validation and modification forms because the drop-downs have many, many K embedded in them, and it can take quite a while for the browser to render 10 validation forms at 50k each.

In Links-SQL, Alex allows the admin to select whether the "Additional Categories" (I'm not sure of the field name field in SQL, it's "AltCategories" in L2) is to be selected from drop-downs OR by listing the secondary categories' IDs in the field. Since Links-SQL is for large projects, it's probably safe to assume that a good number of us will have a large number of categories and that many of our links will relate to more than one of those categories. The prospect of keeping a chart to cross-reference category names to ID numbers in order to create these cross-category relationships does not appeal to me. Alex has, indeed, asked for my thoughts on an alternative, but -at the time- I didn't have any ideas worth exploring. Since then, I've installed Widgetz Expirator mod in L2, and it's methodology sparked a VERY rough concept, i.e.,

Would it be possible to have a category name search available to the admin that would produce a list of categories, description, and their ID numbers? Even better, could those individual categories returned in the search have a checkbox that, when selected, would post those categories (either by name or ID) to the "Additional Categories" field.



[This message has been edited by bjordan (edited August 29, 1999).]

A search seems like a possibility, but remember, that html/cgi is not interactive.

The _best_ option, and I think I mentioned it before, for large sites, is a Java applet that reads the list of categories ONCE, then allows you to search/sort/select and inserts them into the html form field.

While I don't particularly like Java, this is an Admin feature, so you wont' have user problems with it.

Because it's processed on the client side, a 50k list of text is still under a 64k windows list box. Most sites don't have more than 3-4,000 categories, or it becomes unweildly. That's what keywords and search is for. Unless you are trying to be an _everything_ site, with no central theme, you won't need that sort of listing.

If you are planning that, then you really should be looking to different software, and 'commercial grade' indexing programs. (Even Alex has indicated that -- not that LinkSQL isn't commercial, but it's well under the $5,000-per-CPU price point). The reason is more for the amount of traffic/hardware and load-balancing a site that large should be getting.

Netscape's Dmoz is:
883,398 sites - 14,887 editors - 146,206 categories

That's about 5 items per category, with 1 editor per 10 categories.

Since some categories on Netscape have 100's of entries... some categories are pretty thin.

But, I'm not arguing size.

I'm planning on about 400,000 links in the next 3 years or so, all of them internal images. My hardware projections are obscene (though I'm hoping technology will advance <G> ) Also, I have doubts about LinkSQL, but this is a 1.0 release, and it's the best place to start. HOpefully, over the next few months there will be additional upgrades, user input, and ideas to help move it from the "next step" to the "last step" <G>.

The commercial grade products have a place in commercial-grade sites where money is changing hands, or a business depends on cutting edge. My business will never need that. We're 'friendly' and if we go down for a short while, hopefully, our friends will wait and come back. We don't _need_ transactions and rollback, though implementing them would prevent problems -- though our problem is defined much differently than IBM, ebay or eTrade would define them.

I guess I wandered a bit because of the Java thing. I'm looking at using Java/FTP for my file uploads, since there are some working examples that use it pretty effectively, and file uploads through the webserver have only webserver permissions, so I'd have to reset them somehow anyway. This starts to make things non-standard, and I _like_ standard

But, if a feature is TRULY admin-only, then implementing it in a solid, well thought, but non-standard way might be ok.

Hence, the Java category applet for Admin, but not Users.

Users would need a search/reload/search-again type interface, since Java crashes browsers, Windows 95/98 and systems somewhat randomly.

Admin's need _FAST_ efficient.

Word has it that 'applets' may take over for much of what CGI is doing. I can see that, to some extent, ie: smart-clients (applets) vs dumb-clients (browsers) but not yet.

Back to 'standard' -- if something is embedded too deeply into the code of the program, then it can't be changed too easily, and thus is by nature, non-standard.

LinkSQL, because of it's large-site nature, has moved out of the realm of a single-programmer-maintainer to a multi-programmer-project and multi-admin-user program. These features need to be built in, and up over time, in a modular and object oriented way, so maintaining and upgrading is logical and possible (easy is a relative term).

Oh well, this is long, and sort of circles the issue. But it's my first post of the day, and the caffeine hasn't kicked in

  The problem is not the 64k list box, rather that each-and-every form created by the scripts have the list box, so tasks that present 10 forms to the admin (like validating) become too large to present via the browser. In the 50k example, if the admin recieived only 30 new links, he'd have to wade through 1.5 megs on his browser just to validate them.

In my opinion, unless one is content with manually posting ID numbers, LinksSQL will not satisfactorily handle even 1,000 categories in Multi-Cat mode.

I could, but if prefer Gossamer Thread's work for several reasons:

1) I have over 25 years experience in software (proprietary small business databases), much of it spent analyzing 3rd-party programs for "fatal design flaws" prior to installation. Over that time, I've learned to trust my gut calls, and my gut says Links-SQL is likely to come together (though it may take some custom coding for the finishing touches).

2) Gossamer Threads is likely to be accessible IF I do need custom work --not always the case with firms writing packages for large commercial customers.

3) These forums. Though you've previously (rightfully) bemoaned the fact that the LinkSQL forum is lonely, there's still no doubt that there is on-going support here. And, the hot Links2 forums have provided a great number of the mod concepts that have been ported over to LinkSQL.

I'm not criticizing LinkSQL, other than it's still immature. It's more mature since it's based on the more mature 2.0, but it still has a long way to go to leave the links 2.0 roots behind, and take full advantage of what SQL has to offer.

I think you mis interpreted what I meant by the 64k list box... that was a reference to java coding, which is still limited by the windows API on windows machines. Staying under the 64k barrier makes things easier. That's what I was referring to. No special handlers would be required, at least initially... for larger lists, the file could easily exceed 200k, but in that case, splitting the list into several category lists, perhaps each root-level, and presenting each as a separate drop down box, that are combined when returned to the program.

If you know Java, you could probably start writing one, at least the client side to manage the list. MySQL is set up to handle Java interaction.

The hard part is devising a workable interface. The rest - sending the data file, and sending the selections back, should be fairly easy.

It would actually make working with all the category information easier, since adding a link to different categories could be done on the client GUI with one update call, rather than several calls with refresh/reload time.

I think #1 should be allowable, since some people would prefer it.

I think #2 -- in java script -- is a great idea. I prefer Java script to java for a lot of reasons. That's the second browser window, I just forgot that javascript could aid it without the overhead of Java.

Hello Mr. Bjordan!



Then what will you do with the categories listings? I am curious if you realized the problem I am discussing.


What Links SQL can do is really much more than a basic script could do. I do not think Links SQL is immature and is in the development stage. It is a script or a set of scripts that is highly highly mature and is of a very very high quality. I have not the slighest doubt about it. If you compare it with many thousands programms on the internet worth a price of few hundred dollars then Links SQL could be on the top still.

The biggest problem with Links SQL is that it has some built-in inherrent limitation that needs to be solved before one really starts a project cooking with this script. Also this are not that so serious that it has bugs or whatever, but only minor updating or revisions so that after one starts the project one is secure that all the later updating complies with it.

If the multiple admin mod comes out later it shall not affect the database data but a change of category table will affect every link and therefore it could be seen as the top most priority, if at all one considers it an area needed to be revised in terms of design.
I beleive Multiple category mod should be able to choose categories from multiple tables and if not then it will only keep on producing extra list of categories everywhere forever. And later it would be impossible to change.

In Links SQL it is the same.

I am of the same opinion. The worst what will happen is when you start the project, it will be impossible for you to change. Because the links will start getting nested with itself that is within the database. I mean the ID of the categories will be chossen from the category table and then you cannot change at a later date those IDs. So one starts with a fixed categories IDs and that remains in the Links table or Alternates table for that matter.
If you start with two tables where a table selector is built-in, then the category IDs are from the begining written everywhere correct. Both those tables will have different themes for the listing of categories. So one has to decide NOW, which direction to take.


------------------
rajani













[This message has been edited by rajani (edited August 30, 1999).]

  Or, if a project is not under severe time constraints, one can post his analysis in this forum. If his arguments are good enough, perhaps Alex will be persuaded to address this very real concern ..... but, in the end, if this is NOT resolved with a table method or some other first-class solution, I will use the ID method, though it is crude relative to the rest of application.

I renamed/moved categories, and I did not hit the problems I had in links 2.0. Because of the way LinkSQL holds the category, when the category table changes, the ID still matches.

For example:

Computers/software/shareware/pim

if you decide to change that to:

Computers/software/pim

All you do is change the category table. The links follow right along.

I would imagine you could 'merge' categories too, with a simple routine to change the old category number to the new one, then delete the empty old category.

I really think I'm missing something, and I'd really like to know what it is if I am! I'm planning a 400,000+ links database, with reasonable levels of categories, and I currently don't see the problem other than the size of the drop down list -- and since I'm on a DSL line, right now, that's not a problem for _me_ but on dialup it would be (and simply for aesthetic reasons, it is).

There are other solutions, such as multiple browser windows, but the limitation is that the browser is a dumb client, and interaction has to be by post/get.

Java is the answer in the long run, unless some other technology comes out. PHP3 is a possible, setting up a second browser window to pick/search the categories and copy the numbers over.

The reason Java is the answer is that it can mimic a stand-alone system.

Otherwise, you'll be sending the category list with every call to the server.

There are a lot of issues here, but the main one seems to be an efficent way of dealing with large categories. What do you think of the following:

1. Let people enter in a category name or a category id. So if you turn db_gen_category_list off, Links SQL will only display a text box rather then a select list. However, you don't need to enter in an ID, but can rather enter in a category name. The script will check that you entered it properly, and return an error if there was a mistake.

2. Create a "Category View" pop up window which would use javascript to display root categories. Clicking on a plus beside any category would expand or contract that tree. This would allow the admin to keep a window open to view the category heiarchy.

Number 1 is very easy, only a couple lines of code. Number 2 would take some more time.

What do you think?

Cheers,

Alex

If using Option 2, the javascript "Category Cross-Reference Menu," wouldn't it be easier to opt for entering the ID number rather than the name? --Less typing.

  DSL! You lucky dog (pun intended)! No chance of that here, my effective dial-up rate has hung around 28K for 3 years now.

Seriously, the huge drop-downs are more than a minor problem.

The options Alex proposed are all great, i think they should all be allowed to chose from when setting up LinksSQL , even let webmasters who dont have alot of categories to keep the category dropdown list.

The solution is easy, you just have to decide which one to take.
i think that precious time should be spent on something like the multiple admin mod.

Thanx