RE: Re: [Project] Kbd/LCD device

[andy.powell@xxxxxxx]

For the Alarm conditions what about SNMP Trap messages - This would have=20
the immediate advantage that any network management console could pick=20
them up... bearing in mind that some devices will be completed before thec
ontroller (or whatever) is complete..

Andy





"Mick Furlong" <dorsai@xxxxxxx>
05/06/2001 13:08
Please respond to ukha_d

=20
To:     <ukha_d@xxxxxxx>
cc:=20
Subject:        RE: [ukha_d] Re: [Project] Kbd/LCD device

I like the thought but this works for IM based on people logging into a=20
central server. I think we will end up going down the central server route(
or=20
a group of resilient central servers NOT necessarily all being PCs) at=20
some=20
point but I realise some people have qualms about this. I think this is ag
ood=20
idea but the status (statii in plural? ;) should not be hard coded rathere
ach=20
device should be allowed to independantly set its own list of Statii. Thec
hallenge for the Management console will then be to handle this free=20
format=20
status. One possible way would be to group them for example an Alarm=20
Condition=20
Group for items requiring attention. Oh well time to grab a sandwich!


Mick

Paul Gordon <paul_gordon@xxxxxxx> said:

> There's some thoughts here though...
>=20
> IM has some interesting features that could be directly mapped so
some=20
> useful functions in a HA scenario...
>=20
> IM uses "presence information" to set instantly changeable
status modes,
>
such as:
> online
> offline
> busy
> on the phone
> out to lunch
> appear offline
> Be right back
> away
>=20
> etc...
>=20
> From a device perspective, I reckon it could be useful to implement
a=20
> similar ability for any device on the network to independantly set
it's>
status to any of several modes, such as:
>=20
> online
> offline
> locked
> do not disturb
> alarm
>=20
> etc...
>=20
> The device could switch between modes independantly according to
it's=20
own=20
> local programming, depending on various conditions, or the
controller=20
could=20
> set it into any mode (for instance, a lighting controller which is
in=20
the=20
> Home cinema room could be set to "do not disturb" mode when
a movie is=20
being=20
> watched, to prevent it responding to lighting commands & turning
the=20
room=20
> lights on during the film)
>=20
> Don't know how practical all this is, but it just struck me when the
IM>
protocol was mentioned, that the presence information features of IM=20
could=20
> be useful for us. - Any device on the net can change status, but
more=20
> importantly, ALL other devices on the net are aware of the status
change
>
almost instantaneously...
>=20
> =A30.02
>=20
> Paul G.
>=20
>=20
> >From: "Broadfoot, Kieran J"
<Kieran.Broadfoot@xxxxxxx>
> >Reply-To: ukha_d@xxxxxxx
> >To: "'ukha_d@xxxxxxx'" <ukha_d@xxxxxxx>
> >Subject: RE: [ukha_d] Re: [Project] Kbd/LCD device
> >Date: Mon, 4 Jun 2001 16:58:18 +0100
> >
> >I agree a simple socket based network protocol is more than
adequate.=20
Do=20
> >we
> >need the complexity of IM or IRC though?  Take a look at smtp or
ftp=20
for
> >instance.  The handshaking and comms is very simple and pretty
much asm
uch
> >complexity as we need.
> >
> >Thanks
> >              Kieran
> >
> >-----Original Message-----
> >From: patrickl@xxxxxxx [mailto:patrickl@xxxxxxx]
> >Sent: Monday, June 04, 2001 4:48 PM
> >To: ukha_d@xxxxxxx
> >Subject: [ukha_d] Re: [Project] Kbd/LCD device
> >
> >
> >
> > > > The model I'm thinking of is more along the lines of
> > > > each client device opening a connection to the
> > > > central
> > > > server, which remains open indefinitely, and which
> > > > is
> > > > bi-directional: either party may send a message to
> > > > the
> > > > other at any time. A good metaphor for this style of
> > > > communication would be any of those instant
> > > > messenging
> > > > protocols.
> >
> >Now there's an interesting starting point (IM).
> >Another interesting starting point could also be a bastardised
> >version of IRC.
> >
> >
> > > > Ideally, I'd like to see each node communicating in
> > > > this way, but I'd also like to see them with a
> > > > simple
> > > > web/cgi interface for configuration and monitoring
> > > > from a browser, and an even simpler remote
> > > > command-line interface (like a really lame telnet
> > > > implementation) for doing the same thing, which can
> > > > also be accessed from a serial interface.
> > > >
> > > > Does that lot make any sense, or am I talking
> > > > bollocks?
> >
> >Spot on mate.
> >
> >Patrick
> >
> >
> >
> >
> >Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms=
/
> >
>=20
>=20
_________________________________________________________________________
> Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
>=20
>=20
>=20
>=20
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/=
>
=20=20
>=20
>=20



--=20




=20

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






*
********************** DISCLAIMER **************************
This message is intended only for use by the person
to whom it is addressed. It may contain information
that is privileged and confidential. Its content does
not constitute a formal commitment by Lombard Odier.
If you are not the intended recipient of this message,
kindly notify the sender immediately and destroy this
message. Thank you.
*************************************************************

=20

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