duplicity-team team mailing list archive

[Michael Terry <michael.terry@xxxxxxxxxxxxx>]

> this is a mapped list, right? 

I'm not familiar with that term, but were you asking what I meant by dictionary?  I meant a python dictionary, like:

a = {'key': 'value'}
a['key'] == 'value'

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

With this API, you'll still have to handle the backend not providing 'last_mod', so why bother telling the backend which bits you want?  Backends can just fill in all the bits that duplicity needs (which for right now is just "size").

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

I'm only leery of over-engineering.  The more we build into the API, the harder it is to write a backend (the ease of which is a nice thing right now).  The rest of the current backend API is oriented around single objects.  If we don't know why we'd need to be able to query multiple files at once, why optimize for it?
-- 
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.