Mobile devices..

[Danny Angus <da...@apache.org>]

Hi,

First of all, thanks for xmlrpc, we've recently finished a public demonstration of a client-server application where the clients are mobile devices (phones, PDA's etc).

The server serves a map and publicly authored content associated with points on the map.

The idea is that as you navigate the city you can leave (author) content as you go, and read/view things other people have authored.
For fuller details of our project see this: http://www.proboscis.org.uk/urbantapestries/index.html

ATM it is pretty much being held back by the lack of network coverage and the poor resolution of location awareness, but it was a research project not commercial software, and proved the concept to the satisfaction of our funders.

So to my point... 
We used XMLRPC to give us ready made RPC functionality across a broad range of client platforms and I'd already used it in another project so I knew what to expect.

The issue we have encountered is that not only is the XML quite big for our limted bandwidth use-case, but parsing it is also quite involved for a limited capability device.

I've seen discussions of zip'ing the xml to cut down on bandwidth, which will might possibly help (or just offload the bottleneck to the device again!), is there any similar action which could be taken to reduce the XML parsing effort, a simpler schema that could be used perhaps?

We deliberately restrict ourselves to only using String's for values throughout, but make much use of structs and arrays.

Have any other users encountered these (or similar) issues, and what, if any, solutions could you share with us?

Does anyone see a way in which we could be using xmlrpc more efficiently?

Thanks for your time, and a great little product.

d.

Re: Mobile devices..

[John Wilson <tu...@wilson.co.uk>]

On 11 Jan 2004, at 14:21, Danny Angus wrote:

> Hi,
>
> First of all, thanks for xmlrpc, we've recently finished a public 
> demonstration of a client-server application where the clients are 
> mobile devices (phones, PDA's etc).
>
> The server serves a map and publicly authored content associated with 
> points on the map.
>
> The idea is that as you navigate the city you can leave (author) 
> content as you go, and read/view things other people have authored.
> For fuller details of our project see this: 
> http://www.proboscis.org.uk/urbantapestries/index.html

Look cool!!
>
> ATM it is pretty much being held back by the lack of network coverage 
> and the poor resolution of location awareness, but it was a research 
> project not commercial software, and proved the concept to the 
> satisfaction of our funders.
>
> So to my point...
> We used XMLRPC to give us ready made RPC functionality across a broad 
> range of client platforms and I'd already used it in another project 
> so I knew what to expect.
>
> The issue we have encountered is that not only is the XML quite big 
> for our limted bandwidth use-case, but parsing it is also quite 
> involved for a limited capability device.


You are using Apache XML-RPC client with MinML?

Is you problem speed or memory footprint?
>

> I've seen discussions of zip'ing the xml to cut down on bandwidth, 
> which will might possibly help (or just offload the bottleneck to the 
> device again!), is there any similar action which could be taken to 
> reduce the XML parsing effort, a simpler schema that could be used 
> perhaps?


It's certainly possible to reduce the number of tags used in the 
message (you don't generally need <value> or <param>) but then you 
would lose the interoperability benefits of XML-RPC.
>
> We deliberately restrict ourselves to only using String's for values 
> throughout, but make much use of structs and arrays.
>
> Have any other users encountered these (or similar) issues, and what, 
> if any, solutions could you share with us?
>

I'm a member of the JSR 172 expert group 
(http://www.jcp.org/en/jsr/detail?id=172) and we looked long and hard 
at the problems of using SOAP on mobile devices. None of the device 
vendors would consider using non standard approaches to reducing 
bandwidth (i.e. a big no to 'binary xml') - they got burned by WAP and 
weren't going that way again. Zipping the data stream is OK, it works 
very well with XML but it is memory and computationally expensive.

I wrote MinML-RPC (see my web site) as an XML-RPC implementation for 
embedded devices with far less resource than the ones you are using. 
It's a server only implementation at the moment but there's not a lot 
of difference between processing an XML-RPC request and a response so 
it's hackable ro a client.



John Wilson
The Wilson Partnership
http://www.wilson.co.uk