duplicity-team team mailing list archive

[edso <edgar.soldin@xxxxxx>]

On 24.08.2011 16:31, Kenneth Loafman wrote:
> I think you two have indeed hashed the design down to it's essentials, so
> here are some thoughts on the issue.
> 
> The idea of get_info(filename_list) is a good idea, but it is not necessary
> to specify what info to return.  It is necessary for this enhancement to

we can add that later, if needed (it's just the placeholder is already there), same goes for the filename_list implementation.
how about 

def list_info(self, filename_list = None, attribute_list = None):
(because it lists info)

> return the size, but most of the backends already do that, they just ignore
> the data.  For example, ftp and ssh both return the results of 'ls -l'
> although ftp may be problematic due to its various flavors.

i expected so, because i am quite familiar with sftp/ftp and know how they work.
are you sure there is no backend that won't deliver a size because that is not part of the protocol or server implemention?

> 
> Initially we just wanted it to return size info on just one file.  Maybe we
> should make that default, but return the info in a list of dicts, i.e.
> [{'name' : 'filename', 'size' : 5555}, ...].  'size' could be set to None if
> the backend is not able to supply it.  

i actually would even (because of the above) not have a key named size if the backend does not deliver it. a size None can still mean there was a computing error or such.

>Then we can just warn the user that
> this backend is problematic and they should verify.

hmm. here i think that duplicity until the resume integration had no issue with this problem, because it always restarted from the scratch. so i'd rather vote to 

make resume optional (--resume parameter) 
OR
tell the user to consider to disable resume (--no-resume) because the backend is problematic and they should verify

> Ede, I am in favor of dicts for this.  foo[5] is mostly meaningless if you
> are reading the code for the first time, while foo['size'] tells you
> something about it.

agreed. can python stack dicts? as filename is the id already it might be handy to stack it like this

{'filename1' : { 'size' : 5555, ... }, 'filename2' : { 'size' : 2222, ... }, ... }

so it can be accessed 

foo['filename1']['size']

..ede

-- 
https://code.launchpad.net/~mterry/duplicity/early-catch-498933/+merge/72607
Your team duplicity-team is requested to review the proposed merge of lp:~mterry/duplicity/early-catch-498933 into lp:duplicity.