Re: [LHA-misc] Line parsing routine

[<HGu...@ao...>]

Ok Jay, This is great stuff.

Just to clearify, before I implement, are the USER/PASS/QUIT optional if a 
agent does not want to handle logins? If using logins, I imagine it should 
actually validate the login on the host machine's users (ie: use the passwd 
file under linux)? Kind of pain for a simple agent. As far as security, it is 
probably better not to let the agent port past the firewall.

I assume what you call Agents is what Neil is calling Deamons (maybe that's 
where I'm mixed up)?

On your OSI Model I always envisioned the UI always talking directly to the 
server. The server in turn talks to the individual agents. This way all the 
communications goes through the server and the server can track the current 
state of the devices.

One minor gripe, the SET command's (and 8000 message) syntax with ADDR= and 
VALUE= is a bit verbose (why can't it just be {noun} {verb} syntac like "SET 
0.x10.A1 ON"? Not a big deal though.

Any chance of getting this turned into a working document on Sourceforge? 
Guess this interface is called AGENT-1.0??

Also, I noticed you talk about NAPCO 9600 (I have one too), do you have an 
Agent running? What do you have that speaks this language?

Thanks,
H. Gunner





In a message dated 11/28/00 12:51:05 PM Eastern Standard Time, 
jh...@fa... writes:

> Not to get out-of-sync with the last posting (in response to another
>  request) you have some good points (Q's) in here that I think need to
>  be addressed:
>  
>  At 12:14 AM 11/28/00 -0500, Neil Cherry wrote:
>  >I've looked over what you've posted so far and it looks good. Now I have
>  >few questions.
>  >
>  > >What I've got implemented as far as commands are:
>  > >USER <user id>
>  > >PASS <password>
>  >
>  >The login/password part is difficult, how does one let an LCD login?
>  >We can allow a default/guest id that is active when they connect. This
>  >would allow monitors to do their work.
>  
>  LCD's/UI's fall in an interesting area (at least the way I think
>  about them) because (1) they generate events and have a proprietary
>  control interface (be it web, lcd, leopard, ...) but (2) they make use
>  of information from other "agents" for display purposes.
>  
>  I see 3 ways to implement them. I have an LCD+ sitting here, still
>  waiting for an LCD-80 to appear (not holding my breath) so I am not
>  to biased towards either of these methods but the nature of the Leopard
>  being a primary agent interface (ADICON) and UI (or multiple UI) almost
>  forces both methods be available.
>  
>  OSI Model (selected pieces):
>  ~3 - Agents
>  ~4 - Server that dispenses events and plays "traffic cop"
>  ~6 - UI handling
>  ~7 - Actual interface (web, ...)
>