Development Status nALFS2
berndt.matthias at gmx.de
Mon Aug 1 02:30:14 PDT 2005
On Mon, Aug 01, 2005 at 02:44:13AM -0500, alfs at linux2themax.com wrote:
> >From what im hearing it seems there is a vagure consensus. duno how
> >much net:ssh in perl supports ie if it supported the key based auth
> >or not. but it seems that ssh is one of the better methods of
> >transport for this I would think there is the ability to write in the
> >ability for the client to loose connection and come back and say
> >continuing connection build system replies ok what line # and
> >frontend system sais i recieve line #25. backend goes ok heres line
> if perl could understand keys then no session info would need to be
> created. you could have the session be tied to the key so when that
> key logs back in alfs notices it as the current session thats
> from what i have gathered it seems most of the base tools are already
> there. I might be wrong in what was being envisioned but that seems
> to me to be the basics of the network based alfs needs. local would
> use unix sock... what protocol to use to allow the data to be sent
> over ssh im not as shure about. I would think the data to the front
> end could just be the terminal info with line #'s at the front. duno
> about how to send the responses to the backend though smtp style
> communication does seem fesible.
SMTP? SMTP sytle?
<irony>Should I get an email for every output?</irony>
> as for the profile transfer i would think that could be done via
> scp/sftp? still tied to the ssh which would be not much more work then
> getting the other communications going.
I don't thought much about this idea, but it doesn't seems to be a
solution because we do not want to have a dumb client. If the client
shouldn't be dumb there has to be an comunication protocol.
Even nALFS(1) could be used over network and with rsync it isn't
uncomfortable. If screen is used even interupted connections are not a
More information about the alfs-discuss