RE: Re: [Project] Kbd/LCD device

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

Ant,

I feel like I am to go on a bit of a diatribe but ill try and keep it
simple.  To the _real_ java programmers out there I apologise if I confuse
any of the things I say here... I think its important everyone realise I am
not a programmer by trade ;-)

Three concepts need to be addressed: Encapsulation, Inheritance and
Serialization

Encapsulation:  The concept that an object can act as a black box to the
application using it.  The object can define a set of public methods which
the using application can access.  How the object does this is irrelevant
to
the external application.  Hence if the lighting controller object defines
a
public method called getStatus the console software doesnt care to know how
it gets this data, i.e the command set used by the object.  If we describe
an object model that purely details what it expects the inputs and outputs
to be to each object (which is a representation of a single device) then we
can manage multiple different devies within a single framework.  It allows
different people to work on different devices knowing we can make them all
talk to each other.  A more complex example would be the LCD object.  The
console need only know that it wants to send a message to the LCD.  It
therefore calls sendMessage(String s), the object can then parse this into
wml, html, bitmaps etc depending on what the device can handle.  Given all
this it makes it easier to define relationships between devices in a way
which does not relate to the physical properties of the devices.  It could
make for a very interesting macro language where you can access the methods
of a device object from a parsed language.

Inheritance: The method generally employed to define this data model would
be to use an inherited device object.  Each device object (written by
whoever) must provide instances of the public methods within the parent
object.  In other words we can define what each device must be able to do
and build the base object.  These methods at the very least would include
getStatus, softStart, hardStart, sendMessage, getMessage (both these use
some form of buffer) etc.  Of course a device can probably do more than
this
so we use a common feature of java which allows an object to be interogated
to determine its public interfaces.

Serialization:  I think this is a cool feature of Java.  If an object
defines itself as extending the serial interface Java has the capability of
readng the object as a byte stream and then instantiating it.  In other
words the object class for the device can be payloaded into the rabbit.  On
startup the console discovers the device and pulls a byte stream from the
object.  At this time the console only knows the device as a generic object
but on receiving the byte stream can instantiate the object and then access
its methods.  Both the firmware and object code are stored on the device.
No need for a floppy with the device driver to be distributed with the
device... plug and play ;-)

My vision of all this is that the console is nothing more than a simple
network stack and a persistent store of information (plus a timing thread
for events built in its macro language).  If you remember the picture I
sent
the frames within the main pages are built from data in the devices object.
It should be borne in mind that complex GUIs dont take up much space as the
bytecode is very efficient space wise in java.

We have two things going on here: discussions about the physical devices
and
protocol (ascii or broadcast) and the more esoteric view in which we
describe the data relationships between devices.  By pulling the two apart
we can build a software model around some very cool devices to make it dead
easy to manipulate the devices and build complex HA solutions.

Anyway I think i am starting to rant but hopefully this helps to define
what
I am thinking of.. Stop thinking about the bit bashing for a while and
think
about the data representations.

All the best

Kieran

p/s If it sounds like I was teaching you to suck eggs I apologise ;-)

-----Original Message-----
From: Ant Skelton [mailto:fourstringmother@xxxxxxx]
Sent: Monday, June 04, 2001 6:34 PM
To: ukha_d@xxxxxxx
Subject: RE: [ukha_d] Re: [Project] Kbd/LCD device



--- "Broadfoot, Kieran J" <Kieran.Broadfoot@xxxxxxx>
wrote:
> Ant,
>
> SNMP is not a bad idea but I am not a fan of
> programming or for that matter
> working with MIBs.

I hear that ;)

> I still think a simple ascii protocol might be more
> than enough for now and
> does allow us to pipe pretty much anything down it.
> Given this it allows
> the object model I suggested earlier self determine
> the meta data to be
> shunted between console and device etc.

I think I see what you're getting at, but I have to
fight the tendency to hide under the bed and go wibble
when you start banging on about meta serializable
object wosnames. Can you clarify this a bit? Assume
you're trying to explain it to a total idiot ;)

> code

Code?

ant

__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35
a year!  http://personal.mail.yahoo.com/



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/