On Thursday 12 of May 2011 16:49:34 Alan Pevec wrote:
adding back augeas-devel and David
On 05/12/2011 02:15 PM, Andrew Beekhof wrote:
> On Thu, May 12, 2011 at 2:14 PM, Andrew Beekhof<andrew(a)beekhof.net>
wrote:
>> On Thu, May 12, 2011 at 11:13 AM, Radek
Novacek<rnovacek(a)redhat.com>
wrote:
>>> Forwarded from augeas-devel. I think the suggested API
could work
>>> for us quite well. Our config agent will be reduced to only one
>>> method "run" which will take string (commands separated by \n) or
>>> list of strings (augeas commands) and some flags (e.g. bool for
>>> suggested AUG_RUN_CONTINUE). This method will return error code and
>>> content of "out" file (maybe parsed somehow).
>>>
>>> Do you agree with this proposal?
>>
>> I think its pretty close.
>>
>> Though we may want to keep frun but alter it slightly to look like:
>>
>> int aug_run_url(augeas *aug,
>>
>> char *url, FILE *out,
>> unsigned int flags)
>>
>> and support at least file://, http://, ftp://
That can do application that calls augeas lib (library for config agent in our
case). It will download the file and then pass the content to the augeas.
>>
>> Not so interesting for DBus, but highly useful in the cloud.
>>
>> Also, I think we want a dedicated "getter" accessor.
Do you mean that this function will do just one query? Or more of them?
>>
>> Something like:
>> aug_get(augeas *aug, char *path, unsigned int flags).
>>
>> But I'm not sure how to get the values out.
>
> s/sure how to/decided which is the best way to/
Instead of everything-is-a-file mantra, what about having callback function
as an argument for aug_run? augeas lib would call it when there's something
to give out or read in. That way client apps can support different sources
if they wish, augtool for example really only needs to support files.
Alan
I don't see any advantage against simple just passing strings? Pass string
with commands and get string (or list of strings) with results.
Radek Novacek