RE: Re: [Project] Kbd/LCD device

["Broadfoot, Kieran J" <Kieran.Broadfoot@xxxxxxx>]

Everyone,

The email conversation myself and John had focused on four things over
about
8/9 emails:

i. TINI vs Rabbit (you can guess how this conversation went... outcome:
rabbit for embedding, TINI as a possible embedded management console)

ii. Choice of language for writing the management tools in... outcome: John
has no preferenced hence I popped for Java for the following reasons:

a. its portable
b. where we need platform dependence we can use RMI
c. It has platform scalability.. javacard through to EJB
d. Supports all modern network technologies
e. Supports pretty much all the markup languages allowing us flexibility.

I have no problems using another language but I do believe it needs to be
an
OO language because of what we need to achieve.  I truly do think that
whatever we put on the pics/rabbits etc that the management of these
devices
should be done as a set of objects derived from a single meta object.  We
can do some groovy things with this model:

a. define dependencies and relationships
b. query the object for a list of its functionality which is great for
intelligent discovery of devices
c. Hides the implementation details away from the console, hence allowing
disparate devices developed in different ways on different platforms to
communicate.
d. The state of devices can easily be mapped to some form of persistent
storage, disk or flash etc.
e. We even discussed a method by which the object for the device be stored
in the devices flash and serialized to the console at run time.

iii. The third item we discussed was the network protocol.  John sent me
some rabbit documentation and I noted that we can run http/cgi on these
devices hence the KISS approach dictates that we use something everyone
knows.  cgi is one of those things and means that people dont need to use
the console tool (bulkhead for want of a better name) but could implement
the control of devices however they see fit.  Note that the protocol we use
in this sense defines the network protocol and not the actual data we
transmit between devices.  HTTP or simple sockets both perform the same
thing just using http makes our life a little easier.

iv. The actual data protocol we use for devices to communicate.  We didnt
talk as much about this but the output of our discussion regarding the LCD
device did determine that its quite hard to decide before we have built
anything else how it would be managed and what data (protocol) it needed.
The lighting design was at that time deemed to be simple in comparison
although if I have followed the John->Keith email flurry I think thats
becoming a bit more complex, HOWEVER.. and its a big however which is why
it
gets capitals if we define the object model correctly we do not care how
the
device communicates or what functions it uses.  An example:

public class LightingController extends UKHADevice {

LightController(Socket s) {
// init the software object here.  probably collect status
from device.
}

collectTools() {
return array_containing_command_set[];
}

// For each command in this array define a method within the object.

queryDevice(Socket s) {
// Do anything you want in here to query the device.
// use byte encoded xml, http, pure sockets, carrier
pidgeon.
return device_status;
}

addSibling(UKHADevice d) {
// define relationships
}

addParent(UKHADevice d) {
// define a controlling device.
}

addChild(UKHADevice d) {
// define relation
}
}

In other words each device and its associated data model is kept distinct
from the management console.  Again this allows any number of
re-implementations etc of the console be it embedded or otherwise as long
as
the object model remains the same.  We could even throw the objects into
corba and handle it any way you want.

The final three methods are there to help each device define its
relationships with each other.  Which will be stored persistently on disk
at
the console and back to flash on the rabbit.

One final thing we talked about is how will devices communicate between
themselves?  We briefly talked about defining a simple ASCII based protocol
such as SMTP and then having this made available to each device and hence
all devices know all command sets.  I think we might be better off saying
that with the data model each rabbit could be informed of its relations and
how to communicate because the protocol is embedded in the data object.

I dont know if this helps explain anything or whether I have just gone off
on a tangent but thats what we talked about and pretty much gets everyone
up
to where we are now.

On a personal note I would love to receive more feedback about some of this
stuff.  I sent two emails about protocols etc to which I have only received
one response.  Like John I'd like to apologise to anyone who may have taken
offence of me going off and starting some code but I want to do something
and without any visible interest I thought I was on my own.  I hope
everyone
proves me wrong!

Thanks
kieran

-----Original Message-----
From: Dr John Tankard [mailto:john@xxxxxxx]
Sent: Monday, June 04, 2001 7:34 AM
To: ukha_d@xxxxxxx
Subject: [ukha_d] Re: [Project] Kbd/LCD device
I am truly very sorry if you feel you need the leave the project, the
off list msgs account to about 10 messages only. At no time was there
any intention to de-rail or divert the project.

About 4 of the messages were about arranging hardware to be sent to
out to Keith the remaining 6 messages can be reposted to the list if
required, I will do that on my return or perhaps Kieran could repost ?

Dont leave.  The LCD/KBD is not dead, but on its own it does little.
Personaly I think that if a project (Lighting) develops to a working
device and I am sure it will, then the other devices will follow. If
we had started with the LCD it is possible that we would have run out
of steam because it has a limited use untill the other devices are
built.

The lighting device also had the advantage that it already exists in
prototype form, which means that a complex device can be produced
quickly and perhaps more importantly it can work without a PC /
control system, it also has a limited command structure which is easy
to define.

If you want there is no reason why some of the group cannot start on
the LCD/KBD while the current project is being developed. I will help
with whatever I can.

If the group as a whole does not like the change to the lighting
control system I will go with the rest, no problem and no offence
taken.

Again please dont leave the group, your input/work is needed.

John.

(Car waiting must go on holiday)




Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/




Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/