RE: Re: [Project] Kbd/LCD device

["Mick Furlong" <dorsai@xxxxxxx>]

Has anyone given any thought to the target component prices for a device
like this? I have been looking around and the numbers stack up fairly
pricey
even if you make it a 'dumb' device.

I am of course assuming people want a 40 Char. x 8 Lines/240 x 64 pixels
display and some sort of membrane type keyboard...I get over ?100 not
including case cabling etc for a 'dumb lcd/kbd.


Mick

> -----Original Message-----
> From: Steve Morgan [mailto:steve@xxxxxxx]
> Sent: 04 June 2001 21:39
> To: ukha_d@xxxxxxx
> Subject: RE: [ukha_d] Re: [Project] Kbd/LCD device
>
>
> > -----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/
>
>




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