Top things to see in first ALFS

jamie bennett jamie at
Wed Feb 2 06:42:28 PST 2005

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?

If we keep to sending the profile 'as-is' i.e. in its XML format wrapped in some
transport wrapper then it makes client programming a lot easier.
As for additional libraries, Python doesn't require an external XML parsing
library, it has one built in.

> Matthias

    --    Jamie

More information about the alfs-discuss mailing list