Big Muscle wrote:
I don't understand this much. How is adding more information into filelist connected with ADC favour to file types?
I was simply saying that things such as bitrate are not as likely to be added (or proposed to be added by large number of people) because DC does not favour any specific filetypes (ie. my comment here was specific to your mentioned example of bitrates not generally).
Big Muscle wrote:
Of course, DC++ supports uncompressed filelists and protocol requires it. How would it work when someone doesn't implement BZIP extension?
So it does, that's good... because it wouldn't be surprising if it didn't considering that every client that supports ADC 1.0 does implement BZIP as far as I know, (besides it wouldn't be surprising if I had missed this because transferring of uncompressed filelist just doesn't happen right now, and it looks like dcpp in fact uncompresses the compressed filelist on the fly before sending if someone indeed does happen to request an uncompressed filelist).
Big Muscle wrote:
Fast connection is whatever where you doesn't have to wait for ages to download filelist.
That is about as ambiguous as just saying fast connection, how long is ages is quite relative... and it also has to be relative to the file size in my opinion. Also don't forget filelists are still mostly regular files with few exceptions to rules here and there but that's it.
Regarding the examples given here, yes filelist downloads should ideally be "fast" but if you really just want to go and browse users filelist, in case they happen to have something that interests you, then you should have picked partial filelist to begin with if possible (I always make my pick based on users total share and what he has set as his connection type).
Regarding speed of filelist transfers in general, if we would really be trying our best to guarantee fast transfer times for them should we not start by looking at prioritising upload bandwidth first rather than using it as an excuse to limit the data in a filelist to bare minimum (ie. even if my filelist is 1mb compressed but my upstream is currently used up by other files, the resulting transfer time could be just as bad as in your examples).
Point: why limit expressive power of filelists in an attempt to guarantee something that can never be truly guaranteed. I am not saying we should add new data to the filelist recklessly but at the same time I dislike that impact on size and (thus) transfer speeds are the first counter arguments when there should be better ways than
just plain size control to keep the transfer times reasonable.
Also, you mentioned GFI command in your first reply as nice as that would be I am sure you do realise that if we want to collect data on multiple files on users filelist through it then it will quickly become undesirable method not to mention that GFI simply asks for RES ie, to effectively use GFI we would need to extend RES or both of them, through an extension, in order to add more info about files.
Big Muscle wrote:
I would also think how timestamp is important. Yes, it allows sorting files in filelist, but how many users really need to sort files in filelist? Most of users just select files and click download. So is it worth to implement it when it has such negative impact on users?
I am not willing to evaluate negative impact without actual data based on real life implementation, speculation is good to start from but it should not end there unless the result is singlehandedly clear.