From xmlrpc-user-return-923-apmail-ws-xmlrpc-user-archive=ws.apache.org@ws.apache.org Sun Jan 11 14:22:26 2004 Return-Path: Delivered-To: apmail-ws-xmlrpc-user-archive@www.apache.org Received: (qmail 59796 invoked from network); 11 Jan 2004 14:22:26 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 11 Jan 2004 14:22:26 -0000 Received: (qmail 66708 invoked by uid 500); 11 Jan 2004 14:22:21 -0000 Delivered-To: apmail-ws-xmlrpc-user-archive@ws.apache.org Received: (qmail 66506 invoked by uid 500); 11 Jan 2004 14:22:20 -0000 Mailing-List: contact xmlrpc-user-help@ws.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: xmlrpc-user@ws.apache.org Delivered-To: mailing list xmlrpc-user@ws.apache.org Received: (qmail 66483 invoked from network); 11 Jan 2004 14:22:19 -0000 Received: from unknown (HELO killerbees.co.uk) (212.229.119.215) by daedalus.apache.org with SMTP; 11 Jan 2004 14:22:19 -0000 Received: from 192.168.0.4 ([192.168.0.4]) by killerbees.co.uk (JAMES SMTP Server 3.0a1) with SMTP ID 243 for ; Sun, 11 Jan 2004 13:34:13 +0000 (GMT) From: "Danny Angus" To: "Xmlrpc-User@Ws. Apache. Org" Subject: Mobile devices.. Date: Sun, 11 Jan 2004 14:21:21 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N 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...=20 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.