Subject: From: Date:

RE: [ECS] CGI advice needed Martin Terry Sat, 29 Jan 2000 20:00:47 -0800

---

Well, I'm not a programmer, but I always that that ECS in the GUI world
would be better split as a client/server type of application.

The "event engine" could operate as the server component, with an API to
talk to the client portion. The API would include the basic components now
implemented in the group/item windows, with the ability to read and set
states of items.

You could implement the "event updates" as a separate compiler with error
checking output. This would allow the "event editor" to be separate as well,
with the ability to parse the new events, save to some compiled opcode form
and then inform the "event engine" to reload the new "config" once it
successfully has passed error-checking/parsing.

I think this would be a great cross platform approach, because the "event
engine" would remain fairly static until new devices/states are implemented.
Changes in the client display GUI wouldn't impact the event processing code
at all. This would also allow you to develop a user friendly "ECS config
builder/event editor" that again could develop and grow without affecting
the other components, but still allow users to "text edit" configs for the
ECS Guru.

The "event engine" would operate as a standard "daemon" in Linux, or a
background process that has no really UI (like a web server). TCP/IP would
be great for the API communications. Maybe even build the web engine
directly into ECS!

So basically 3 main components:

Event engine - loads a precompiled config and runs it. Understands and
responds to an API for Shutdown/Stop Processing/Get Item State/Set Item
State/Load Config (for starters)

Event Editor - Use to update configs/events/items. Reads a text file as is
done now, but is designed as a "ECS programming compiler". Outputs a text
config and precompiled "config file" that can be loaded by the event engine.

Client GUI - Group/Item display and control. Communicates directly to the
event engine via TCP/IP. Can be run on a separate machine, even across the
internet.

Optional components (at a extra cost perhaps):

Web engine plug-in.
Multiple client GUI option (like ACE)
Whatever else Mark dreams up...

Just a thought. There's probably tons of example code on TCP/IP socket API
usage, any SMTP server code would be a good example, or web server code.

-----Original Message-----
From: Mark Gilmore [mailto:omnip@usit.net]
Sent: Saturday, January 29, 2000 5:08 PM
To: ecs-list@netbloc.com
Subject: [ECS] CGI advice needed


Hi all,

NOTE:An embryonic ECS/LINUX is now "operational", in that it
executes Events and supports most serial-devices (less the
modem and the NAPCO). Still lacking is sound support and a
user-interface (other than scrolling status text).

Rather than manually re-invent yet ANOTHER user-interface for
ECS/LINUX, I thought that I would be better off creating a
HTML/CGI-based interface that could be used on multiple platforms
(e.g. Win AND LINUX). BUT before diving into anything, I would
appreciate your sage guidance :-):

1) Is this a good approach ?
   If not, why not, and what would be a better approach ?

2) Should I use PERL, JAVA, or something else (and why) ?

3) How could the CGI best communicate with ECS ?
   NOTE: The DDE interface (with some additions) would work fine under
   Win (if I could interface it to the CGI), but I would prefer a method
   that could be applied on all platforms.

4) Can you provide an IDIOT's description of how YOU would to it
   (including a basic description of the data/control flow and what
   software does what) ?
   Please remember that I am VERY green on CGI/PERL/JAVA/etc.

THANKS
-- 
Mark Gilmore
Omnipotence (ECS home automation software)
http://www.usit.com/omnip
423-745-0026

---