Re: [Config4gnu-developer] Transport Level ?

[Alexsandr M. <ale...@ba...>]

Hi.
> I'm thinking specifically of gnome-vfs, (see http://www.gnome.org/ and
> http://developer.gnome.org/doc/API/gnome-vfs/) but I know there are oth=
ers.
> Is a dependency on gnome-vfs a bad thing? Are there any other libraries=
 out
> there that could do this?

I think it's a bad idea, cause:
1) libgnome-vfs requires 27 different libraries to be installed in the sy=
stem=20
(at   least version installed at
   my home system), and i think it's no good for a system which aims to w=
ork=20
at different distributions.
2) we don't really need all the functionality of gnome-vfs (or kioslave o=
r=20
some other vfs system)
   , we just need something like a CUPS backends, specialized programs
   used to send/recieve configuration files, basing on URI.

I attached a small .eps diagram to illustrate how i see the transport lev=
el.

The algorithm is:

1. Middle level, basing on URI, fires up the specific transport (for exam=
ple=20
file transport for URI beginning with 'file:/').
2. Transport retrieves a configuration file(s) into some local configurat=
ion=20
cache (for example into: /var/spool/c4g/conf-cache/tmp.node231/...).
3. Middle level tells specific parser to process data from cache.

> Also consider this:
> The current implementation on CVS has the back-ends (the parsers) runni=
ng
> as separate processes from the front-ends. This allows the parsers to b=
e
> written in any programming language. Whatever transport layer it uses t=
o
> access the configuration files is up to that particular parser.

I don't feel it's a right thing to let parser know where
the configuration files are and to access them directly.
Parsers, imho, should access configuration located
in some local configuration cache and do not mess with a
distribution specific configuration file placement policy.

> -- FYI for readers in general: an explanation of parsers/unparsers
>
> parsers - read an application-specific configuration file and represent=
s it
> using an XML representation.
>
> unparsers - a rather bad term (how do you unparse?), but it takes the X=
ML
> representation and writes out the application-specific configuration
I consider "unparser" a bad term too, but i just don't know how
to express that kind of thing with a short term. Some suggestions ?

BR
    Alexandr Mikhailov

P.S.
    By the way, how do you see the middle level ?
    I think it has to be a server to implement a normal access-controls.