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