> >> 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 ;). > > But no reason to invent some complicated thing that all backends have to > support. Why not do get_info now, and if we ever find an actual use for a > list of info and we want to allow backends to optimize it, we can add a new > get_list_info that certain backends can provide, which if found will be used, > else we can fake it, iterating over a file list, calling get_info on each > entry.
i explicitly try to avoid the 'backend has to support' here. my solution would be a backend.py::get_info() that returns an empty list. backends can override that with an own get_info() that returns information and the calling code has to decide what to do according to the return data (empty list or meta data). > I'm just saying, we can optimize later for this problem we don't even have > right now, rather than requiring all backends to implement a more complicated > function. this is not optimizing but API design. backend.py's main method right now are def put(self, source_path, remote_filename = None): def get(self, remote_filename, local_path): def list(self): def delete(self, filename_list): where the two latter actually return a list or take a list as argument so they can deal with lists and with singles. it seems to me only natural to have a def get_info(self, filename_list = None, attribute_list = None): which returns a list. if you really implement the list functionality is up to you. you might want to throw a NotImplementedError if the list contains more than one item, but the interface will be stable and we don't have to modify the calling code after we decided to support lists. maybey we should call it list_info instead as it lists info. >> 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? > > Backends already do try multiple times. But it makes sense that if we > havne't yet tried the maximum number yet, retry until we do hit the cap. that's what i meant... thanks all for your efforts btw. ;) ..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. _______________________________________________ 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
