Development Status nALFS2

Mark Ellis markp.ellis at ntlworld.com
Wed Jul 6 05:48:23 PDT 2005


On Tue, 2005-07-05 at 21:39 -0500, James Robertson wrote:
> Matthias Berndt wrote:
> > Greetings,
> > 
> > some time ago the development of nALFS2 was mentioned on this list, but
> > it's silent since these days. Even the wiki semms to be lonly now.
> > 
> > I want to know what's going on with this idea?
> > 
> > Regards
> > 	Matthias Berndt
> 
> Matthias,
> 
> Thanks for your interest in alfs (was nALFS2).  I read yours and 
> Jeremy's posts.  The SRS is not designed to answer your questions.  It 
> is designed to provide a framework for making those decisions. 
> Actually, the communications subsystem is an area we need to work on 
> first IMO.  We need a modular system that can support a variety of 
> communication mechanisms.  I was think of unix sockets for 
> localhost/single box client/server comm and then maybe a daemon of some 
> kind listening on a tcp port or something for simple secured network 
> comm (like a company intranet).  We also need a secure remote comm 
> protocol for Internet based comm.  I don't know anything about d-bus and 
> so cannot make a statement there.  I just know that I want to be able to 
> run the alfs daemon on a minimal system to build a box out - like the 
> livecd.  So the backend daemon needs as little add-on software as 
> possible.  This is why Jeremy wants it in C.
> 
> If you want to plug in and "waste" some time as you put it, we could use 
> some help fleshing this out and getting the team to agree on it.  We can 
> use the wiki for a lot of it and this list.  I don't really think it 
> would take long.  At the least we need a spec for the modules and then a 
> spec for how a unix sockets module would work and be implemented.  Once 
> that is done, code away.
> 
> Mark - I saw you are back - want to help?
> 
> Thought?
> James

I agree that the communication system needs to be specified first in
something like this. One of my longest standing TODO items for perl alfs
is to rewrite the comms protocols. It's a lot trickier in an existing
system, so getting it right to start with is vital.

The details of how comms are performed are, I believe, not as important
a question as what you want to say and do. Having said that, the
protocol is tricky while the 'medium' is easier, so I'd start with the
latter :) Since the backend should be as lightweight as possible, a
straightforward socket connection would seem the way to go, then it's
easy to upgrade from there eg. with ssl or ssh for encrytion etc.

As for the protocol, start thinking about the different kind of messages
we'll need, appropriate responses etc. I'll make some attempt at
documenting my current protocol (gulp) but off the top of my head...

1) hello, i'm a new frontend
2) heres a profile, execute it please [ from step n ]
3) this is the current command and it's output (info from backend)
4) I have a problem, what shall i do ? (question from backend)
5) abort/pause/resume the profile (as response to 4 or not)
6) i've finished the profile, its exit status is....

Then how do you cope with lost connections, and stuff like that.

More mechanically, do you want xml coded comms packets (which is how
perl alfs works, not my decision, it's how i found it), simple text
commands as used in SMTP, FTP et al., numeric codes or something else ?

Does a profile get sent over the control connection or a separate data
connection ? If a separate connection, does the front or backend assign
it some kind of id so both sides know what they are referring to ?

I'm starting to ramble.....

Mark





More information about the alfs-discuss mailing list