duplicity-team team mailing list archive

[edso <edgar.soldin@xxxxxx>]

On 23.08.2011 22:49, Michael Terry wrote:
>> 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'

i am no pythonist, so yes a key->value list is called a map in java and was what i meant

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

because it is the more elegant approach. you were worrying about too much info by default. ok, so we know which info we need, so let's request it. if we can't get it, we'll get a no key=>value pair for it, so we can deal with it.

performancewise it also makes sense, becuse no info is requested that is not needed.

we'll probably end up with backends, that won't/can't tell us the size anyway, so we should design the api with the possibility to deliver a NULL info. we simply cannot know if every backend is going to deliver it. this way we could easily implement a dummy method in backend that returns an empty list and implementing backends can overwrite and return whatever they are capable of is requested.

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

except of list() of course ;)

> If we don't know why we'd need to be able to query multiple files at once, why optimize for it?

that's exactly the reason we don't know! 

i actually believe that some extra thought in application design will save you the extra hours of doctoring afterwards. so therefor i plead to keep the API open. that does not mean that everyting is to be implemented. it just means that you don't restrict yourself without any need for it. so why restrict the return value to one value set, if we can as well wrap this by default into a list again, just to have the possibility to return a list of dictionaries for several files.

in this case it means we add a new interface like get_info() that backends are free to implement. if they do, some extra duplicity functionality kicks in. if not, then it does not ;).

another thought:

why do we actually log an error here? shouldn't we try num-retries to put the file on the backend and only fail if that does not work out?

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.