Subject: Re: J2ME limitations Was: PacePutDelete Withdrawn

From: [email-masked]
Date: 16 Jul 2004 12:06:36 -0000

--- Janne Jalkanen <[email-masked] wrote:

> The issue is with
the default Java J2ME MIDP implementation, and 
> specifically the HttpConnection
class which only allows the verbs GET, 
> HEAD and POST.  I have no idea
why this decision was made.  Probably 
> because those cover 99.99% of all
HTTP traffic.  Note that this also 
> affects any prospective WebDAV clients
on J2ME.

I have explained the possible reasons in my previous mail
to the group, but everybody seems to be ignoring the opinion of a wireless
expert.

> However, there are two - no, three - ways around this:
> 

> a) you can write your own HttpConnection class, which allows any verb.
 
> It'll just increase the size of your application, no worries.  You can

> even take Sun's source code and modify it slightly, and then use that
(I 
> haven't looked at license issues here).  
> This is however possible
only 
> on MIDP 2.0, as 1.0 does not have a SocketConnection.

I would
not advice anybody to do this because:
a) it leads to usability issues. F.e.
if your network operator requires a http proxy, you will have to provide a
different input screen for the user to enter the proxy address. This will
not only confuse the user, because he needs to enter it twice on his phone,
but sometimes the phone comes preconfigured by the network operator and the
user might not even know what a proxy is.
b) it leads to considerable bloat
of the application code: about 15 KiB extra, which for something simple as
an atom client could be up to half of the application.
c) It will not always
work on all phones. If a user is only connection over WAP by the operator,
he not be able to use this workaround.

> 2) Do not use Java, code directly
on top of the Operating System (say, 
> Symbian or PocketPC).  For many purposes,
this is already the preferable 
> choice.  No such restrictions are in place
when you access the code 
> natively.  It also allows you to do other cool
stuff like link to the 
> phone internal databases, or access the multimedia
functionality (such 
> as the camera).
> iii) Write a proxy that can translate
your near-atom-protocol into 
> fully-fledged Atom protocol.
> 

This
is not a workaround for MIDP, this is just ignoring the most viable existing
phone application platform in the galaxy.

> I would however, like to point
out that XML-RPC/MetaweblogAPI still 
> exists and works.  Atom is not going
to kill it for a long time.  So, 
> the question is, do we want to ensure
maximum support for all mid- and 
> low-end cell phones (where the average
replacement time is very fast 
> anyway) now, or do we just say that "work
around it, or use XML-RPC, the 
> situation will get better in two years."

Aha, are you suggesting to require Atom servers to support MetaWebLog
API?
Also the base64 encoding for uploading binary objects through metaweblog
API is still a problem.

> The first choice will increase the complexity
of the spec, the latter 
> will make it simpler, but the adoption rate will
slow down.
> 
> However, it's not like "by ditching SOAP, we'll prevent
anyone with a 
> cell phone from ever again blogging."  The situation is
not that grim.

No, it's more like: by requiring other methods such
then GET, HEAD and POST in Atom, you will make it impossible to deploy Atom
on 80% or more of the cell phones, capable of running downloadable applications.

Peter

---

From: Sam Ruby <[email-masked]>
Date: Fri, 16 Jul 2004 08:57:41 -0400

> to the group, but everybody seems to be ignoring the opinion of a wireless

Please don't give up on us yet.  I'm pretty sure that we will get it 
eventually.

- Sam Ruby

---

From: Janne Jalkanen <[email-masked]>
Date: Fri, 16 Jul 2004 17:33:10 +0300

>to the group, but everybody seems to be ignoring the opinion of a wireless
Well, yeah.  I didn't see your email before I sent mine :-).  I just 
wanted to provide another point of view, which is that the situation is 
not that grim.

But it is something that *needs* to be considered.

>he not be able to use this workaround.
I agree on all points.  But it is *still* a workaround.  I can't even 
say whether our own phones use the default HttpConnection class... It 
might be that it's slightly modified, in which case this workaround 
might fail horribly on some devices.

>phone application platform in the galaxy.
In the galaxy?  :)

Well, it is workaround to the problem as such.

> Aha, are you suggesting to require Atom servers to support MetaWebLog
No, but I am just suggesting that *most* servers that will support Atom 
already support MetaWeblog API, and Atom will *not* obsolete it 
immediately.  So it is possible to use it as a workaround.  Of course, 
there's a penalty involved.

>Also the base64 encoding for uploading binary objects through metaweblog
True.

>on 80% or more of the cell phones, capable of running downloadable applications.
Not impossible.  Just more difficult.

It's just a question of priorities.  My point of view is that this *is* 
an important subject, and that unless we want to ignore a very rapidly 
growing user segment (and make many developers rather unhappy), we do 
want to support a GET/HEAD/POST -only way of using Atom.  We *can* 
ignore it, which will result in a bunch of unstable and hackish 
applications, but it does not make it impossible to make an Atom client 
on Java MIDP.

Actually, I'm all for a Atom-Action header wrapped inside a POST (the 
alternate solution in PacePutDelete).  That would solve most of the 
problems in a rather simple way.  We wouldn't even need to go for base64 
in binary uploads (like in PaceSimpleResourcePosting).

So +1 for reworking PacePutDelete and using the alternate solution.  In 
case nobody else does it by Monday, I can grab it and rewrite the pace.

/Janne

---

From: Mark Baker <[email-masked]>
Date: Fri, 16 Jul 2004 10:56:43 -0400

+1

-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca

  Seeking work on large scale application/data integration projects
  and/or the enabling infrastructure for same.