duplicity-talk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Duplicity-talk] backend query_info question


From: edgar . soldin
Subject: Re: [Duplicity-talk] backend query_info question
Date: Sat, 31 Dec 2011 13:49:34 +0100
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0

On 30.12.2011 17:59, Michael Terry wrote:
> Hrm.  Those methods are "a private method which is not supposed to be
> overwritten and only used within one object".  They are implementation
> details of each backend implementation, called only by Backend itself.
> 
> I was trying to use a paradigm where Backend could act as an
> intermediary between the rest of the code and the backend
> implementations.  

i see your argument. still, from a object oriented point of view all backend 
implementations are inherited from the base backend object, hence they also 
implement query_info by default. actually there is no point in treating both 
classes differently.

> It can guarantee behavior from query_info that
> put/get just can't because it wraps the _query_file_info method
> provided by those implementations.

although i am not finished, while working on the info retrieval for sftp i 
modified the code so that backends do have to create dummy values if they have 
none. this makes it more fault tolerant and easier for implementers.
on a second thought, having managed that i see no real need for a generic 
query_info anymore. it could be put in each backend and each decides if it 
wants to loop or not according to list retrievability or not. 

> And by encouraging the underscore for backend implementation methods,
> we make it clear that this is not a method that the rest of the code
> should be calling.  It's internal to the Backend class.

but it keeps people from implementing as they assume these are private methods 
which are not part of the API.
easy enough we can keep them for the backends you already altered and just add 
a query_info to each.

> 
> That said, I don't feel strongly about it.  If ya'll like it without
> underscores I can make that change.

i could do that together with the changes mentioned above.


..ede

> 
> -mt
> 
> 2011/12/30 Kenneth Loafman <address@hidden>:
>> I agree.  It should follow the same naming convention as get/put/list/del.
>>
>> ...Ken
>>
>>
>> On Fri, Dec 30, 2011 at 7:03 AM, <address@hidden> wrote:
>>>
>>> I see the point of confusion here. Usually a leading underscore points to
>>> a private method which is not supposed to be overwritten and only used
>>> within one object.
>>>
>>> Removing the leading underscore from _query_*_info methods and add your
>>> hint to the query_info description comment should clear this up for future
>>> implementers. Don't you think?
>>>
>>> ..ede
>>>
>>>
>>>
>>> On 30.12.2011 07:20, Michael Terry wrote:
>>>>
>>>> Yeah, query_info is newer than the get/put calls and was done in a way
>>>> to allow individual backends to provide optimized ways of asking.
>>>>
>>>> So if a backend can query multiple files at the same cost as one file,
>>>> it should implement  _query_list_info.  Otherwise, it should implement
>>>> the simpler _query_file_info.
>>>>
>>>> A backend shouldn't reimplement query_info itself.
>>>>
>>>> -mt
>>>>
>>>> On 29 December 2011 19:43, Ken Bass<address@hidden>  wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> I am writing a backend (for the idrive/ibackup online storage) and am
>>>>> confused about the query_info().
>>>>>
>>>>> Is a backend supposed to (optionally) provide query_info, or
>>>>> _query_list_info or _query_file_info? It is rather confusing as to which
>>>>> is
>>>>> really supposed to be provided and I wasn't sure what the leading
>>>>> underscore
>>>>> was for.
>>>>>
>>>>> Initially I was just thinking of providing my own query_info, which is
>>>>> consistent with implementing other calls such as get, put, delete,  but
>>>>> then
>>>>> when I looked at some other backend code, I noticed _boto, couldfiles,
>>>>> gio,
>>>>> local and u1 all go the _query_file_info route. No one appears to be
>>>>> simply
>>>>> implementing the query_info themselves.
>>>>>
>>>>> _______________________________________________
>>>>> Duplicity-talk mailing list
>>>>> address@hidden
>>>>> https://lists.nongnu.org/mailman/listinfo/duplicity-talk
>>>>
>>>>
>>>> _______________________________________________
>>>> Duplicity-talk mailing list
>>>> address@hidden
>>>> https://lists.nongnu.org/mailman/listinfo/duplicity-talk
>>>
>>>
>>> _______________________________________________
>>> Duplicity-talk mailing list
>>> address@hidden
>>> https://lists.nongnu.org/mailman/listinfo/duplicity-talk
>>
>>
>>
>> _______________________________________________
>> Duplicity-talk mailing list
>> address@hidden
>> https://lists.nongnu.org/mailman/listinfo/duplicity-talk
>>
> 
> _______________________________________________
> Duplicity-talk mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/duplicity-talk



reply via email to

[Prev in Thread] Current Thread [Next in Thread]