duplicity-team team mailing list archive

[edso <edgar.soldin@xxxxxx>]

On 23.08.2011 22:08, Michael Terry wrote:
> ede, making resume optional is a good idea (maybe a --no-resume option).  But that's a separate bug/branch.

it is, but assuming your agreement i'll open a topic on the mailing list about it. i actually vote for a --resume option, because currently it actively seems to disrupt backups of users trusting that it'll work.

> 
> As for get_info() vs get_size(), I'm nervous about getting *all* infor we can.  That might be a lot, and some info is more or less expensive on different backends.
> 
> See, for example, all the info the GIO backend could request of a file: file:///usr/share/doc/libglib2.0-doc/gio/GFileInfo.html

thanks for the web link, actually i do not at all use or develop for linux desktop, therefor i am very grateful for any hints in that direction.

> 
> I'm sure we could come up with a reasonable subset of metadata to query, but adding more later isn't so hard.

well hardcoding the info needed in the method name is not futureproof. actually i also don't wanna see a method for every info available.

> 
> What about a get_info() method that returned a dictionary?  And for an initial pass, we would only have backends fill out a "size" entry.  That way, if we later discover some piece of metadata we want, we keep the same API and can just edit the backends.

this is a mapped list, right? 
i'd also suggest a path [mask?] parameter and a property list parameter. this way we can  ask for 

get_info("path/to/file", ("size","last_mod") )

> 
> Now, as for whether get_info() should return information on a list or a single file...  ftp and sftp can operate on multiple files easily, but there would be no savings to do so.  We'd ideally want to verify after uploading each file, so we're still making the same number of remote requests.  And we're not saving computationally, because getting info on the whole list is asking for more information than we will use.

i just considered the limitation of the backend protocol here. i am very aware that a backend capable of asking for the meta data of one file, should internally of course map it that way. i was just argumenting API-wise, and for the api it'd make sense to be able to return lists instead of atomic data sets. who knows what we'll need it for in the future.


ede/duply.net


-- 
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.