Hi folks,

Something just crossed my mind, and I needed to consult the ADC draft. I found the search chapter not to be very compelling.

3.3.5 SCH;
"Clients that don’t recognize a field should ignore the search."
Is this really a good thing? Why not "Clients that don’t recognize a field should ignore the field?" What if some smart-ass invents a brilliant new 2-char operator that works perfectly in parallel with the 'old' operators? If client don't even reply on the search (which is the behaviour specified in the current draft) then we'll be back in the today so beautiful client incompatibility issues from version to version... And you all know what I'm talking about - hubs banning for client versions <x and/or >y and/or <z etc etc... There has rarely been a month in 2004 where new banning rules for versions haven't occurred. Are we striving for more of this? I usually don't use the term "backwards compatibility" but here it needs to be mentioned I'm afraid.

Another thing about searches, the default of the 'TY' operator doesn't work as searches in the current DC protocol, where today you search for both directory names and filenames. This isn't even supported in ADC unless you use 2 different fields "TY1 TY2", or am I missing something? If it's not too much to ask for, I'd like a third option, its meaning being the binary combination 3 [file or directory] _and being the default_.

And the third thing about searches; Yes TTH relieves stress on passive searches, but _many_ searches are still and will always be - manual searches of strings typed by the user. To be more specific (and unstressing also) people use the 'File type' modifier today. Is there no such thing in ADC? To specify audio files, you have to use whole bunch of fields such as EXmp3 EXogg EXwav etc..? That increases the search packets for no reason, and people _will_ want to have file types and clients _will_ implement them, and the same file types will this way be propagated as text through the hub. Is this a feature? I can't find the good reason.
I'd like today's file types, and I'd like them to be flags, for multiple usage, such as audio being 1, video 2, images 4 and then the pseudo file type 'multimedia' becomes the binary combination 7...

I'm sorry if I sound like irritated or so, it's not the case, I'm just tired today, a bit sick as well.
But thanks again for showing interest in what I have to say :)

Opera

-- 
DC Developers mailinglist
http://3jane.ashpool.org/cgi-bin/mailman/listinfo/dcdev