[Date Prev][Date
Next][Thread Prev][Thread Next][Date
Index][Thread Index]
RE: Re: [Project] Kbd/LCD device
- To: <ukha_d@xxxxxxx>
- Subject: RE: Re: [Project] Kbd/LCD device
- From: "Steve Morgan" <steve@xxxxxxx>
- Date: Mon, 4 Jun 2001 21:39:24 +0100
- Delivered-to: rich@xxxxxxx
- Delivered-to: mailing list ukha_d@xxxxxxx
- Mailing-list: list ukha_d@xxxxxxx; contact
ukha_d-owner@xxxxxxx
- Reply-to: ukha_d@xxxxxxx
> -----Original Message-----
> From: patrickl@xxxxxxx [mailto:patrickl@xxxxxxx]
> Sent: 04 June 2001 21:01
> To: ukha_d@xxxxxxx
> Subject: [ukha_d] Re: [Project] Kbd/LCD device
<snip>
> So if you put a web server on both ends of the relationship, you can
> do push. That's a rather unusual way of looking at things.
Not that unusual at all, really. As I mentioned, it's used for n-tier
application architectures that use HTTP (or SOAP) as the RPC layer for ease
of integration.
> A (not very good) analogy would be if, in order to download a file,
> you first had to install a full blown ftp server on the device you
> wanted to download the file onto.
A variation that appears at work is a client uses Telnet into the server
and
then calls an FTP client on that server to 'pull' the requested from the
client. In this case, yes, the client implements an FTP server. However,
not
all servers have to be 'full blown' servers. You don't have to implement
IIS
or Apache on an embedded device in order to offer HTTP server support. TINI
is a prime example. This is commonly used to add Web Server support to
devices. They've even used it to implement a web server on an electric
bicycle.
> Either way, you have to remember that we are dealing with devices
> with very limited capabilities in terms of processing power and
> storage.
But do-able. TINI, again, is a prime example.
> I can't see a tangible benefit from forcing these devices to
> talk a cut down version of http. With the exception of the console,
> these devices will only be talking with other embedded devices.
Why? It's the fact that you can easily open up access to virtually any
device that I like.
If I have a browser interface to a device, I can control that device from
any machine in the house (or across the Internet) without needing any other
embedded devices. However, if I expose Web Services, things start to get
even more interesting. If a device exposes a Web Service using SOAP and
provides a WSDL file describing its interface, I can integrate those
devices
into my HA software without any knowledge of proprietory protocols and
exploit them to the full. I also don't need to know what devices I'm going
to have available when I'm writing the code.
IMHO, there are far too many proprietory protocols for communicating
between
embedded (and standalone) devices. I want something that really is
plug-and-play.
> SOAP sounds interesting. Anyone want to provide a definitive URL?
http://msdn.microsoft.com/soap
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Home |
Main Index |
Thread Index
|