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.
_______________________________________________
Mailing list: https://launchpad.net/~duplicity-team
Post to : duplicity-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~duplicity-team
More help : https://help.launchpad.net/ListHelp
