RE: Re: [Project] Kbd/LCD device

[Ant Skelton <fourstringmother@xxxxxxx>]

Sorry about the wacky indenting - it's an artefact of
my finally having sorted my yahoo mail out. Hopefully.

> > Surely you can use HTTP POST to submit info as
> > though a form had been filled
> > in ???
>
> Yes, but it's still initiated by the HTTP client, a
> POST is effectively a GET with a bunch of extra
> information attached. There's no way for the HTTP
> server to initiate a connection to the client.
>
> For example, say you have John's lighting
> controller,
> which has a built-in webserver. It provides webpages
> which allow switching on and off of lights, setting
> dimming levels etc. This is fine for controlling it
> from a web browser, or by using some client software
> which presents a different UI but uses the
> underlying
> HTTP/cgi interface for actually making the
> controller
> do something.
>
> Now imagine that Keith and John have cocked up the
> maths, all the triacs have blown, and things are
> starting to cook nicely in there. The management
> software has noticed, and wants to send an "I appear
> to be on fire" message with some urgency to a
> central
> controller. There's no way for it to do it, because
> webservers aren't designed to communicate like that.
>
> Your only options here are for the controller to
> periodically poll all the webservers on all lighting
> controllers on the offchance that they might have
> burst into flames. Alternatively, you could run both
> an HTTP server and an HTTP client on each node, but
> that would lead to a truely horrible design, and
> it's
> inefficient.
>
> This is what I mean by client-pull: everything is
> initiated by the client. HTTP was designed for a
> client to open a connection, say "I want this",
> receive it from the server, and then go away again.
> Netscape tried to address this with their horrid
> 'server-push' multipart-MIME/replace mechanism, but
> I
> think even they have admitted that it was a bad idea
> now.
>
> 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.
>
> 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?
>
> cheers
>
> 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/