Top things to see in first ALFS

Matthias Berndt Berndt.Matthias at
Wed Feb 2 07:28:25 PST 2005

On Wed,  2 Feb 2005 14:42:28 +0000
jamie bennett <jamie at> wrote:

> Quoting Matthias Berndt <Berndt.Matthias at>:
> > The client has to parse the profile to give the user a chance of
> > intervention. After that you want so send the profile to the server
> > with some additional information about what and how to be executed
> > and the server has to parse the profile again. IMO sensless
> > duplicated work.
> I think your missing the point a bit. The current idea for alfs is
> that the client is only going to read and display the profiles and
> allow you to add/edit/remove bits and pieces. It need not know how the
> server is actually going to implement the function on the target host.
> For example, a <download> tag may be implemented on the server as a
> wget, a curl, or some other network transport method. 
> The client should be _dumb_ when it comes to the actual XML
> translatation. The server on the other hand will take the profile and
> actually do the intelligent bit. If each client has to first parse the
> XML, translate it into some kind of language the server will
> understand and then send it, the server will still have to _parse_ the
> stream at the other end. Why not just keep it all XML?

Am I right when thinking client gets and parses the profile,user (for example) what to be executed, client sends modified profile (or something equal) to server and the server executes the modified profile?

I think ui/backend (multiple backends at the same time) describe better then client/server what i had in mind.

More information about the alfs-discuss mailing list