Sorry Eric For The Private Responce**

Quoting eric <[email protected]>:

> But I really dont care what protocol is chosen I only have a couple
> requests/suggestions
>
>   In Search Results Send an extra integer defining clients inet speed so
> the info dosnt need to be
>   retrieved from the server userlist(although this result isnt necicarly
> true at least it will save some
>   cpu while parsing).

Perhaps we should take the problem from a different point of view: is a user

list really necessary ? Most of the time, we will "private-chat" with either

someone we have received a search reply from or someone we already knows. A command like "$IsOnline nickname[,nickname...]|" is probably better (moreover, the hub can notify a client when the user with the given nickname

enters).

Hmm i think you may have misunderstood the request i agree a filelist isnt really that importatant my point is as far as i know in a "$SR" no inet speed is sent so you can only fill the "Speed" column by checking against the server userlist for each result.

>   Also in search results I think a Feild should be set aside for fileinfo > ie movie dimentions or music
>   bitrate and time.

It looks good but these informations are meaningless (quality of non-lossless

format mainly depends on the quality of the initial source), fairly hard to obtain (you must process all shared files) and will create clients which are

unable to be maintained because there is dozens of file type and new ones are

regularly available.

i wouldnt say meaningless, mp3's for example i feel is safe to say likely the initial source is a cd so bitrate would be nice to know and track time is cool no matter the quality for movies or music.. and dimentions although not a valid guage for quality may help. also i beleave the codec refrance is in an avi file header might be nice when choosing what version of a movie you want.
when i said "a Feild should be set aside for fileinfo"

i think it should just be one field so there can be either no info or just helpfull info about the file if available.. i would prolly only support certin types in my client if it where available because im not up for writing a ton of header info functions.. i have writen avi/mp3 already.
(i dont think we need result|bitrate|freq|dimentions|time  added in the protocol result|fileinfo[|Speed ;o)] i think would be good.. maybee delimit fileinfo with a different chr or not just read it as is and maybee show it as a tooltip in results listview.)


on another point(on a napster client i was working on and am currently updating) loading of 3500 mp3's with header info takes 15-20 seconds on my computer. without tag info <2 seconds. so i wrote a caching function that saves a basic txt file with the info .. loading header cache + 3500 mp3's takes <3 seconds(cache also will detect and get new info for uncached headers).

another thing we know is users are stupid they like to see file info it makes them feel like they know what there doing. :o)

Eric

Tim-