[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: XML and embedded systems
- From: John Wilson <email@example.com>
- To: James Spink <firstname.lastname@example.org>, email@example.com
- Date: Sat, 27 Jan 2001 23:32:53 +0000
have a look at XML-RPC (http://xmlrpc.org) .
It is reasonably simple and there are many implementations available. It's
not 100% suitable for embedded systems with very limited resources (but then
I don't know anything in the XML universe which is - XMLers are big systems
The Wilson Partnership
5 Market Hill, Whitchurch, Aylesbury, Bucks HP22 4JB, UK
+44 1296 641072, +44 7976 611010(mobile), +44 1296 641874(fax)
----- Original Message -----
From: James Spink <firstname.lastname@example.org>
Sent: 26 January 2001 21:27
Subject: XML and embedded systems
> (long note warning)
> I'm a newbie to the XML world. I have a problem I'm hoping others may
> seen and may have suggestions on:
> I have an embedded system that I'll need to communicate data to and from a
> client. Generally, the client will make a request and the server will
> respond, i.e. with data, success/failure, etc.
> In particular, the client will need to be able to get and set some
> parameters on the system. Some of the items are fairly complicated
> structures or lists, while others are simple strings. The list of items
> that the system needs configuration for will vary based upon what the
> is installed into. In addition, over time, the device may evolve
> function requiring new or changed parameters. The connection to it will
> TCP/IP but of limited bandwidth and only directly to/from the client.
> This system will have a JVM and HTTP server available. Adding something
> like Java servlet capabilities is a possibility. XML came to mind as a
> to communicate this data since its flexible, has rich toolsets available
> multiple languages, and can communicate data layout as a part of the
> payload. It could even be used to have the device tell what items it
> supports and how. This device doesn't necessarily have to present an HTML
> interface for configuration, though it could. There will be two principal
> clients - the manufacturer of this device (who wants to set it up in
> quantity) and the service center that uses this device (who wants to
> periodically change some device parameters on individual devices). Both
> these environments place a higher value on a client-side programmatic
> interface rather than a user interface as they usually wish to minimize
> typing when dealing with the device. The client could for example
> and consume the XML directly, or use supplied libraries to produce/consume
> the XML.
> Has anyone dealt with this before? My current thinking is to keep it
> and use my own XML grammar - XML at its simplest, so to speak. One way I
> thought of would be to transmit the XML via HTTP by using a POST
> and placing the entity in the HTTP message body, then respond with XML.
> I could do something simpler and simply send an XML-encoded request over a
> socket and respond using XML.
> I've looked at some of the many technologies invented for XML, but most of
> them seem like overkill for this scenario. There aren't databases
> nor is this going to be an Internet application.
> Jim Spink
> Get your FREE download of MSN Explorer at http://explorer.msn.com