auto match queue + don't delete filelists

[synthmeme]

On a number of hubs, some members would prefer that you not frequently re-download filelists, and instead prefer you to set the option not to delete filelists and open their filelist from your own cache when you want to check their share. This, in effect, prevents you from using the auto match queue feature, as it attempts to re-download a filelist every time a match is found regardless of whether you have a saved copy of that filelist.

It would be nice if, with auto match queue on search and the don't delete filelist options set, auto match queue would use your cached version of the filelist rather than attempt to re-download the list each time. This could be tied to another config parameter that specifies an age of stored filelists after which a new one will be downloaded for the next match queue request (in # of days).

Thanks.

[GargoyleMT]

This can easily become a nightmare from a help/support and a user's point of view.

First off, I'll state that there's no way of knowing when a list has been updated (or not) in the DC protocol - you can guess based on share size, but even if the share size hasn't changed, the contents of the list could have.

So what happens when a two users are trying to exchange files, and are doing /refreshes, but have just downloaded the old lists? How does the user request that the cached list not be used?

That's just the most extreme form, but since there's no elegant solution to how this can be handled, without confusion on the user's part, this won't be coded into DC++.

[Gratch06]

Send TTH hash of file list to requesting user, compare to hash of existing file list, take the obvious action. I'd assume that to compute a hash value for a filelist ( definitely < 10 MB ) at runtime is very quick.

[GargoyleMT]

Well, any unique number would do - if DC++ maintains an "index" to its cache of file lists - including the remote timestamp of when it's updated.

Many, many ways to skin a cat here.