You are viewing a plain text version of this content. The canonical link for it is here.
Posted to rpc-user@xml.apache.org by Peter Carter <pe...@pbc.ottawa.on.ca> on 2002/09/26 10:34:22 UTC
PalmOS
I regularly use RMI to do java on my palm, which works fine except
issues with rmid/registry. After looking at the RPC/XML code and
playing with it, I got hooked.
However, the client has two issues when making a Palm java app. 1) The
client makes use of Vector, which is not supported; 2) Use of the
java.net.* package is not supported, instead javax.microedition.io is
supposed to be used.
I realize item 1 could be a bit of a hack, but using the basic io
package could be quite simple. Personaly, I think this package is a
perfect fit for mobile palm/phone pim java use, as it piggy-backs on
existing tech.
has anyone thought along these lines before?
Re: PalmOS
Posted by Peter Carter <pe...@pbc.ottawa.on.ca>.
This does seem to be what I needed, thanx.
On Friday, September 27, 2002, at 08:03 AM, Nikolajus Krauklis wrote:
> Did you try to look into kXML-RPC package ?
> http://kxmlrpc.enhydra.org/
>
> kXML-RPC is a J2ME implementation of the XML-RPC protocol
> built on top of the kXML parser
> --
> nikolajus krauklis
>
>> However, the client has two issues when making a Palm java app. 1) The
>> client makes use of Vector, which is not supported; 2) Use of the
>> java.net.* package is not supported, instead javax.microedition.io is
>> supposed to be used.
>>
>> I realize item 1 could be a bit of a hack, but using the basic io
>> package could be quite simple. Personaly, I think this package is a
>> perfect fit for mobile palm/phone pim java use, as it piggy-backs on
>> existing tech.
>>
>> has anyone thought along these lines before?
>>
>>
>
Re: PalmOS
Posted by Peter Carter <pe...@pbc.ottawa.on.ca>.
This does seem to be what I needed, thanx.
On Friday, September 27, 2002, at 08:03 AM, Nikolajus Krauklis wrote:
> Did you try to look into kXML-RPC package ?
> http://kxmlrpc.enhydra.org/
>
> kXML-RPC is a J2ME implementation of the XML-RPC protocol
> built on top of the kXML parser
> --
> nikolajus krauklis
>
>> However, the client has two issues when making a Palm java app. 1) The
>> client makes use of Vector, which is not supported; 2) Use of the
>> java.net.* package is not supported, instead javax.microedition.io is
>> supposed to be used.
>>
>> I realize item 1 could be a bit of a hack, but using the basic io
>> package could be quite simple. Personaly, I think this package is a
>> perfect fit for mobile palm/phone pim java use, as it piggy-backs on
>> existing tech.
>>
>> has anyone thought along these lines before?
>>
>>
>
Re: PalmOS
Posted by Nikolajus Krauklis <ni...@avc.lt>.
Did you try to look into kXML-RPC package ?
http://kxmlrpc.enhydra.org/
kXML-RPC is a J2ME implementation of the XML-RPC protocol
built on top of the kXML parser
--
nikolajus krauklis
> However, the client has two issues when making a Palm java app. 1) The
> client makes use of Vector, which is not supported; 2) Use of the
> java.net.* package is not supported, instead javax.microedition.io is
> supposed to be used.
>
> I realize item 1 could be a bit of a hack, but using the basic io
> package could be quite simple. Personaly, I think this package is a
> perfect fit for mobile palm/phone pim java use, as it piggy-backs on
> existing tech.
>
> has anyone thought along these lines before?
>
>
Re: PalmOS
Posted by Nikolajus Krauklis <ni...@avc.lt>.
Did you try to look into kXML-RPC package ?
http://kxmlrpc.enhydra.org/
kXML-RPC is a J2ME implementation of the XML-RPC protocol
built on top of the kXML parser
--
nikolajus krauklis
> However, the client has two issues when making a Palm java app. 1) The
> client makes use of Vector, which is not supported; 2) Use of the
> java.net.* package is not supported, instead javax.microedition.io is
> supposed to be used.
>
> I realize item 1 could be a bit of a hack, but using the basic io
> package could be quite simple. Personaly, I think this package is a
> perfect fit for mobile palm/phone pim java use, as it piggy-backs on
> existing tech.
>
> has anyone thought along these lines before?
>
>