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-