RE: Re: [Project] Kbd/LCD device

["Steve Morgan" <steve@xxxxxxx>]

Sorry, Ant, but I think this is bollocks!

;-)   <--- deliberately inserted cheesy grin

There's absolutely nothing to stop a 'server' initiating a connection to a
'client' device, it's just that the 'client' needs to be able to accept a
HTTP connection.

People assume that HTTP is one-way because they're used to the WWW model
where browsers interact with servers. However, HTTP, being nothing more
than
a connectionless protocol, works just as well in a peer-to-peer model where
devices act as both client and server. You can even see this to an extent
with application architectures such as .NET, where a web server may act as
the client to another server using SOAP.

Server-client communication using HTTP doesn't work well in a standard
browser-based environment because HTTP is connectionless. It'll work fine
if
a 'peer' wants to tell another 'peer' that something as happened, it just
can't do it within the context of a connection unless additional context
information is included, if you get my drift.

I disagree that running a HTTP client and a HTTP server would lead to a
horrible and inefficient design. A HTTP server can be very simple (there's
several available for TINI alone) and a HTTP client even simpler,
especially
as it's not a browser.

FWIW, I reckon that SOAP would still be an excellent way to go. You don't
really need a full-blown XML parser to implement it, if you keep the
constructs simple, but it makes it a piece of cake to extend. The overhead
of a SOAP envelope would be more than compensated for by the ease of
integration into virtually any client - if there's sufficient capacity in
the micro.

Cheers,
Steve

> -----Original Message-----
> From: Ant Skelton [mailto:fourstringmother@xxxxxxx]
> Sent: 04 June 2001 16:34
> To: ukha_d@xxxxxxx
> Subject: RE: [ukha_d] Re: [Project] Kbd/LCD device
>
>
>
> 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/
>
>




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