Re: [LHA-misc] Line parsing routine

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

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

Problem is #7 can be a real interface or #7 can be forced back through
layers 1-3 because it is a hardware device. With that in mind:

(1) Web/Program (non-hardware) UI devices sit at 6/7. They talk to
the server and display info. Login is easy to accomplish in this
picture.

(2) A UI interface "logic" sits at 6 for communications with the server
and agents and implements its own 1..3 for talking to an LCD/etc. Easiest
and the most flexible. This lets the UI app implement menus, receive
events from the server, and submit commands to the server. Problems are
(a) I don't see this working well for things like the Ocelot that support
both UI and sensors (we need a term for these!) and (b) it forces the
program providing the UI to be running on the system with the physical
hardware interface.

(3) A UI app that runs at layer 6 so it gets the benefit of sitting
"on top" of the server but it also opens "agents" directly, manages
it probably via module-specific commands (it means a UI app can't be
100% generic) and receives 8xxx/9xxx events as things happen. The
"UI" events probably need to be a different 8XXX code so they can be
filtered from the server (the UI app will interpert them, navigate
menus, then submit events to the server). This allows management of
the Ocelot via the normal agent commands for all the control and via
MODX commands for the display.

My preferred methods are (1) and (3) as appropriate.

The short version is *devices* don't log in - they are managed - they
may *implement* a login for user functions but that is at a higher
level.

>  But logins would have to be
>through a secure channel (no plain text). That one we can leave for
>a while.

If it is not over internal hard-wire (rs485, Ether inside a firewall)
then I agree 100%. Remember, most (all) of these logins will hopefully
be to a web/UI agent on the upper layers where security is already
defined. I realize sometimes *I* may want to log directly into an
agent (the wife complains that it is 45 degrees inside and the system
has her locked out) but I don't see that as a normal occurrance.

I'll leave off the rest of the comments and continue with the other
document after you've had time to absorb. A lot of it is addressed
in that document - note that some "commands" have different names -
the one I posted in the beginning was from a March email between us
and the full document was pulled from notes and running code (closer
to reality).

Jay