Re: [LHA-misc] Line parsing routine

[Jay H. <jh...@fa...>]

At 07:02 AM 11/29/00 -0500, you wrote:
>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 don't see a problem not implementing it. Just need an error message
for 'not implemented' and make sure the server side understands (and
teach people ctrl-]/close for getting out of telenet )


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

An Agent is a type of Daemon - On the Daemon side you have some that talk
to physcial interfaces (I'm calling them Agents), some that gather and
manage info from Agents (loosely called a "server" or I think Neil has
also used 'lhad'), and some that use the info from the server to make
decisions and send requests back to the server (that then forwards them
back to the agents).


>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.

I do agree with this model and it works very well for GUI/Web type
devices. It also works pretty well with the Leopard because it is
well defined how to handle screen changes, button presses are events,
etc.

I run into a problem that grays the lines on something like a NetMedia
LCD+ that has a keypad, 4x20 LCD, and 8 inputs. It is a physical
hardware-attached device with a protocol and has inputs. It fits the
definition of what an Agent would control.
- How do you send it lines to display?
- It needs interactive data from other "agents"
- Keypresses aren't mapped to a specific event like the Leopard
In short, it needs processing. It needs to feed the "server" like
an agent so everything can see the inputs but the program processing
it needs visibility to everything to.
On possibility is to attempt to define a set of commands for UI's
so generic stuff could be handled but at the moment I can't wrap
my arms around the definition of what will be on the other end for
UI's where the "raw input/output" side I could grasp at the moment.

I know I didn't answer your question but I hope you see the problem
I ran into. It also makes the "server" a little more complex at the
moment...


>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.

Thought about this but experience says go with the more verbose:
- Remember it is primarily programs using this, not humans.
- Tagged values make for forward/backward compatibility and allow the
    'SET' command to do more stuff later:
    'SET ADDR="..." Value="On" AT="9:30" length=":30"' to a *server*
- The tag method is 98% to XML/SOAP where I think this will end up:
    <SET><ADDR>...</ADDR><VALUE>ON</VALUE></SET>
- It maintains uniformity across everything for parsing/building
    messages because nothing except the initial keyword is positional.
    Going to XML nothing is positional (unless you count nesting
    as positional)

>Any chance of getting this turned into a working document on Sourceforge?

I don't have a problem with it - it is still on the rough side and I
don't know how to do much on sourceforge yet (Neil?).

There is also key stuff missing to make all this work like...
"Upon issuing a SET command, when confirmation is received that the
command has been executed or the command is executed in an environment
without confirmation, an 8XXX event will be issued to notify all
listeners of the change in state."

This enables you to hop on the alarm agent, set the alarm, then the
event will get fed back to the server so it can do all the HVAC
setbacks, turn off the TV's, lights, ...  and we don't have to
worry about things getting out-of-sync. It also lets somebody run
multiple "servers" of different flavors for testing/evaluating/...

>Guess this interface is called AGENT-1.0??

Had to come up with some sort of identification.


>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?

I have the basics of an agent working, capturing info, and the address/
domain structure laid out but not fully implemented. Do you have the HA
ROM so you get a full time event feed?

DISCLAIMER: Remember these are my opinions and don't represent the
thoughts of anybody but myself. This is Neil's project and we have
chatted about a lot of this but it does not represent his opinions.

Jay


>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, ...)
> >
>_______________________________________________
>http://lists.sourceforge.net/mailman/listinfo/linuxha-misc
>To unsubscribe, send "unsubscribe Linuxha-misc"
>in the body of a message to  Lin...@li...