Adding dates to filelist

Discussion and questions about clients
Toast

Adding dates to filelist

Post by Toast » 07 Dec 2010, 10:53

Wanted to propose adding dates to filelist so that it gets easier to see whats recently been added into a client this way you can sort dates instead of guessing whats new.

Crise
Senior Member
Posts: 139
Joined: 10 Nov 2007, 21:34

Re: Adding dates to filelist

Post by Crise » 07 Dec 2010, 13:30

Toast wrote:Wanted to propose adding dates to filelist so that it gets easier to see whats recently been added into a client this way you can sort dates instead of guessing whats new.
To be more explicit about this, we should at least say that it should be the file modification time (in case creation time > modification time then use creation time). Also unix timestamp seems the only feasible choice for the actual data that I can think of.

As for the idea itself it would have its uses...

cologic
Junior Member
Posts: 41
Joined: 21 Jul 2009, 19:34

Re: Adding dates to filelist

Post by cologic » 07 Dec 2010, 14:39

Crise wrote:
Toast wrote:Wanted to propose adding dates to filelist so that it gets easier to see whats recently been added into a client this way you can sort dates instead of guessing whats new.
To be more explicit about this, we should at least say that it should be the file modification time (in case creation time > modification time then use creation time). Also unix timestamp seems the only feasible choice for the actual data that I can think of.

As for the idea itself it would have its uses...
(1) Neither modification time nor creation time suffices to handle people moving files into and out of their share. The file move operation does not change modification or creation date on either Windows or Linux to my knowledge.

(2) Subtract list does this already. If it's the first time one sees someone's share and thus can't use subtract list, why does one care what's old or new?

Crise
Senior Member
Posts: 139
Joined: 10 Nov 2007, 21:34

Re: Adding dates to filelist

Post by Crise » 07 Dec 2010, 16:21

cologic wrote:(1) Neither modification time nor creation time suffices to handle people moving files into and out of their share. The file move operation does not change modification or creation date on either Windows or Linux to my knowledge.
True, however, the use I see for this is to see if certain file is recent rather than whether it is new in the share of user X. Also in many cases when user does add file to share it is a newer file than the rest there. Since he either downloaded it or otherwise got it, created on his system, I don't see user suddenly wanting to share 3 year old (old on his system) file as a common scenario unless it is for some specific reason or for a certain person (in which case magnet link could be used).

As for filelist "diff" for that substract list is the way to go, however, for a glimpse to the age of the file a date is better. Also subtract list is tedious in that you actually have to keep old filelists around and, correct me if I am wrong, this does not happen by default. Also I may add that the existence of this feature or its use is not very common knowledge (tested by asking on a random hub what subtract list was).

Edit: also subtract list is dcpp specific feature, with which we can not convey any info on file age to third party, instead they have to a) use dcpp based software (or implement the feature) and b) meet the prerequisites for it (ie. long term storage which is not necessarily desired since chances are we never see user X after the first encounter).

Big Muscle
Junior Member
Posts: 39
Joined: 01 Jul 2008, 19:27

Re: Adding dates to filelist

Post by Big Muscle » 15 Dec 2010, 11:31

I am against adding anything into filelists, because filelist would grow in huge size then. We have GFI command for such purposes.

Toast

Re: Adding dates to filelist

Post by Toast » 15 Dec 2010, 15:47

i just want a way to sort stuff in share by date thats all who ever can make such an implementation without modifying to much is most welcomed to discuss it.

cologic
Junior Member
Posts: 41
Joined: 21 Jul 2009, 19:34

Re: Adding dates to filelist

Post by cologic » 15 Dec 2010, 16:56

Big Muscle wrote:I am against adding anything into filelists, because filelist would grow in huge size then.
This should be an empirical question, not a vague handwavy claim. Pretorian and I played with this on toy (a few hundred bytes)-sized filelists and saw modest (10% or so I think, after bzip2) increases. Given representative measured data, filesize growth is a reasonable concern. Otherwise, that filelists "would grow in huge size then" is just an unsubstantiated hypothesis/assertion. And I write this as someone skeptical of the overall utility of this proposal.

So, BigMuscle, if you want to use filelist size increases as an argument against this proposal, please get data on that. Otherwise, I at least will simply dismiss this as a concern; I can't speak for others, but I'd suggest that they do as well.

(Conversely: it'd be nice to get data on filelist size increases from those proposing this too. But for the moment, only Big Muscle has used this as an explicit argument for or against including timestamps in filelists, so he bears the burden of evidence/proof.)

Crise
Senior Member
Posts: 139
Joined: 10 Nov 2007, 21:34

Re: Adding dates to filelist

Post by Crise » 15 Dec 2010, 20:28

Concerning impact on filelist size, I would see this a problem if we were talking about this matter 5 to 10 years ago.

The point being that the capability of the internet connections today is entirely different from back when the matter of what filelist should contain and shouldn't contain was brought up last time.

Also if ADC is meant to be truly extensible then the filelists should be treated the same way in regards to changes as the protocol is (as the spec does by permitting additional client specific info outside the schema, now that I looked it up).

Size is of course a concern, but considering what I have said and that we also have partial filelists these days I can't really see it as an immediate show stopper when it comes to stuff that involve changes in the filelist.

Big Muscle
Junior Member
Posts: 39
Joined: 01 Jul 2008, 19:27

Re: Adding dates to filelist

Post by Big Muscle » 17 Dec 2010, 19:57

I didn't say that I am concretely against timestamps. I talked in general, because now we add timestamps, next time it will bitrate, then something more, then something more etc. and it will grow and grow. It's true that the difference in size won't be so huge when using bzip2, but remember that BZIP is only ADC extensions and not all clients must support it. Also not all users have fast connections - maybe they have in US or in Sweden, but there are tens of other countries. And it will be a pain in ass for such clients and countries.

pR0Ps
Junior Member
Posts: 29
Joined: 05 Dec 2010, 11:35

Re: Adding dates to filelist

Post by pR0Ps » 18 Dec 2010, 03:08

Big Muscle wrote:I didn't say that I am concretely against timestamps. I talked in general, because now we add timestamps, next time it will bitrate, then something more, then something more etc. and it will grow and grow. It's true that the difference in size won't be so huge when using bzip2, but remember that BZIP is only ADC extensions and not all clients must support it. Also not all users have fast connections - maybe they have in US or in Sweden, but there are tens of other countries. And it will be a pain in ass for such clients and countries.
I am in complete agreement with this. I have never personally had the need for having timestamps in the filelist and don't see the advantage to doing so. Timestamps can also be modified, making them unreliable in discerning which file is actually newer, you will get spammers messing with the value in order to make their file seem newer than the legitimate versions.

Unless you want to devise a method for optionally sending all metadata, there really isn't even a point. Timestamps by themselves are pretty much useless, but all metadata would be useful in some circumstances. Only as an option though, as people with slower connections would hate the added bloat.

I personally can relate to the speed issue. I am currently living in rural Canada and my internet is provided by a wireless tower a few miles away. It's better than dial-up, but not by much. I get dropped a lot and every bit counts. However, I can see that some people would want more information in their filelists. I propose a compromise:

The option for metadata seems like a valid implementation. Call it the extended filelist. I propose that clients that support the extended filelist could generate two filelists, one with metadata, the other without. The "$Get <file>$<offset>|" command is pretty open ended. Clients that support the extended filelist would be able to accept a variation and return the file list that was requested. It would be easy to specify that "$Get MyList.DcLst$1|" gets the regular file list, while "$Get MyList.DcExtLst$1|" would get the extended filelist with metadata. Depending on which $Get command was sent to them, clients could choose which filelist to send. It would also be backwards compatible with the current method, as clients that don't support it would just send the regular "$Get MyList.DcLst$1|" and not know any better.

Thoughts?

Locked