Subject: AtomME: Posting from a Java mobile phone via the Atom API

From: Russell Beattie <[email-masked]>
Date: Tue, 27 Jul 2004 21:14:02 -0700

Sorry for the delay on this, I just ran into a bug I couldn't work out, 
then got caught up in other issues and couldn't get back to it until 
this evening.

Last week we were deep in the POST vs. PUT/DELETE debate when I started 
working with Sam Ruby on a simple J2ME app which would post to an 
Atom-enabled weblog via J2ME. Sam did the heavy lifting of working out 
the Base64 and SHA1 encoding in J2ME-compatible Java (which he published 
on his weblog last week) and I used that code to create a small J2ME 
application which simply allows you to post a title and content field to 
a weblog.

If you want to just play with the app on your mobile, I added a link to 
the .jad/.jar to a WAP page, which you can get to from my short url:

http://rbeattie.com/wap

Navigate to Links, then "Install AtomME". It should download and 
install. I tested it on the phones I have handy at the moment: a Nokia 
7610, 6200, SonyEricsson 616 and a Motorola v400. It's a *very* basic 
app - the J2ME equivalent of a command-line program. I usually use this 
sort of code as a harness to test J2ME functionality. It simply allows 
you to fill out a form with your posting information for a server like 
TypePad (in fact it defaults to their API) then dumps out the XML being 
passed over the wire to the screen.

I've posted the code under an MIT license here:

http://www.russellbeattie.com/download/AtomME.zip

In order to use it, you'll need to have Sun's Wireless Toolkit (WTK), 
Ant, and Antenna installed. Edit the build.properties file to point at 
the at the directory where the WTK is and you should be able to compile 
it quickly. To run the app in the emulator, simply type "ant emulate."

There were several problems getting this working. First, the Base64 and 
SHA1 code is non-trivial, but Sam has gotten that down to a small class 
which I just grabbed and included, but if I had to develop that myself 
it wouldn't have happened. The second problem was the date formatting. 
Some phones (like my beloved, but flawed Nokia 6600) have real problems 
with the Calendar object. I finally gave up trying to get that phone to 
work.

And thirdly and most importantly, neither TypePad nor Blogger (my two 
testing servers) supported chunked HTTP posting. For various reasons 
having to do with unreliable wireless networks, the J2ME Connection 
class will chunk the HTTP whether you like it or not. I did find a way 
of  not forcing the chunking by not calling OutputStream.flush(), but 
that only works on some phones and if the data gets long enough the 
KVM/JVM will still chunk whether you like it or not. Since chunking is 
part of the HTTP 1.1 spec, I don't feel this isn't a big deal in terms 
of the Atom Spec: the servers just have a bug at the moment which they 
need to fix.

So my thoughts are this: SHA1 encoding isn't bad if you have someone 
else write it for you ;-), setting headers on the phone works (at least 
on my carrier), and if POST were the only HTTP verb required, Atom could 
be implemented on a wide variety of handsets right now. The fact that 
this app runs on the 6200 and T616 show a lot - those are *not* very 
powerful phones.

This is just a first step. I'm sure someone can take this code and build 
on it to create a more full-featured Atom client which can do much more. 
For example, using the MultiMedia APIs, it should be possible to post 
PNG images and maybe even video via Atom from J2ME as well.

The next step is for everyone who has a Java-enabled mobile to try the 
app. (Feel free to send bug reports to me, just don't expect a prompt 
answer. :-) ) Do you have a phone which doesn't work? We'll have to 
figure out why - maybe it's a bug, maybe it's something more serious. Do 
you have a carrier which strips out the headers? Etc. etc. Then  we can 
move on to trying to implement the SOAP-based PUT/DELETE alternative and 
see how well that works. I would *much* rather have some sort of action 
header or stanza, as it would make this code much more reusable and 
maintainable, but let's try what's speced now and see.

Thanks,

-Russ

---

From: David Czarnecki <[email-masked]>
Date: Wed, 28 Jul 2004 00:58:09 -0400

> maintainable, but let's try what's speced now and see.

Personally I like the alternative proposal of PacePutDelete [1]. As an
addendum to what I wrote [2] this evening, this proposal seems to be one of
the simplest things that could work without requiring SOAP on the client and
server. It's not that SOAP enabling is hard, but implementing this (at least
how I've got things working in blojsom) would only be a couple lines of code
to check for the appropriate header and route things accordingly.

-David 

[1] - http://www.intertwingly.net/wiki/pie/PacePutDelete
[2] - 
http://www.blojsom.com/blog/blojsom/2004/7/27/atom-blojsom-http-put.html

---

From: Russell Beattie <[email-masked]>
Date: Wed, 28 Jul 2004 10:50:53 -0700

+1

I hadn't seen that addendum until now. I suggested a header alternative 
to the HTTP verb months ago. It's easy to understand and easy to 
implement. It's definitely my preferred option, rather than mess with 
SOAP or an additional "action" tag.

However, right now the servers out there are using SOAP (or should be). 
What I was suggesting is that anyone advocating hand-coding SOAP is more 
than welcome to edit the J2ME code I published and implement it to see 
how well it works with the current servers implementations. I think 
we'll find that a simple additional header will be much easier on 
everyone involved.

There was some concern in the list that some wireless carriers might 
strip out the request headers. Part of the purpose of the J2ME 
application sample was to see if that was the case. If it is, then we 
have more problems because the security won't work either... but if not, 
I think the the X-ATOM-METHOD is a *great* alternative.

Seriously, we could have something up and running on millions of clients 
tomorrow if it was that simple to do.

-Russ

---

From: David Czarnecki <[email-masked]>
Date: Wed, 28 Jul 2004 13:49:49 -0400

It seems as if a new proposal, PaceAtomActionHeader [1] is open. Sam, can you
add this to the AtomPubIssuesList [2] in the "Not Yet Taken up Or Need to
Revisit" section? 

-David

[1] - http://www.intertwingly.net/wiki/pie/PaceAtomActionHeader
[2] - http://www.intertwingly.net/wiki/pie/AtomPubIssuesList

---

From: Ken MacLeod <[email-masked]>
Date: 28 Jul 2004 13:02:34 -0500

Russell Beattie <[email-masked]> writes:

> I hadn't seen that addendum [to PacePutDelete] until now. I
> suggested a header alternative to the HTTP verb months ago. It's
> easy to understand and easy to implement. It's definitely my
> preferred option, rather than mess with SOAP or an additional
> "action" tag.

Note, PacePutDelete was withdrawn and the part that was the addendum
was reincarnated in PaceAtomActionHeader.

    http://intertwingly.net/wiki/pie/PaceAtomActionHeader

  -- Ken

---

From: Sam Ruby <[email-masked]>
Date: Wed, 28 Jul 2004 16:52:59 -0400

> we'll find that a simple additional header will be much easier on 

 From a Java client perspective, the essential change is to replace a 
conn.setRequestProperty with one or more xml.append statements.

> have more problems because the security won't work either... 

There is a syntax defined for encoding this information in the body:

http://www.oasis-open.org/committees/wss/documents/WSS-Username-02-0223-merged.pdf

- Sam Ruby