Subject: Re: PacePutDelete Withdrawn

From: [email-masked]
Date: 15 Jul 2004 17:59:19 -0000

> That's overstating the situation, I think. What we have been told is

> that certain versions of CLDC and MIDP don't support PUT/DELETE out of

> the box. I've been told that it's possible to subclass whatever class
is 
> implementing the HTTPConnection interface to allow any method you 

> desire. I guess the ideal way to prove this would be a working demo.
>

I guess you have been told wrong.

MIDP1.0/2.0 only requires support
for GET, HEAD and POST methods. It might be that some implementations also
support other methods, but f.e. MIDP on series40/60 does not.

The workaround
you suggest is simply not possible for multiple reasons. PutDeleteSupport
also still mentions a non-workable workaround. Maybe, that's were you got
the idea from?

> Even if it's *impossible* to send a PUT with MIDP, that
doesn't mean 
> these phones can't use Atom. Developers can still use the
underlying 
> platform (e.g. Series60). 

The largest contigent of MIDP
enabled phones, f.e. Nokia's mass market series40, don't have an equivalent
open C++ development platform. They only support MIDlets.

- Peter

---

From: [email-masked]
Date: 16 Jul 2004 14:40:13 -0000

--- Sam Ruby <[email-masked] wrote:

> [email-masked]
wrote:
> > 
> > I  don't have any problem with a SOAP alternative for text
objects. I can
> > live with the additional processing requirements and increased
payload size
> > of the SOAP envelope.
> > I do have a problem with
base64 encoding and additional
> > gzipping of binary content, in order to
tunnel binary objects over SOAP, when
> > there exists no simple POST alternative.

> 
> Peter, you impress me as an engineer that understands tradeoffs.  My

> question to you is how important is the ability to not have to 
> base64/gzip
in the specific scenario of a PUT (i.e., replacement) 
> operation?  My presumption
is that editing of existing documents is a 
> relatively infrequent operation.

I would like to see a primary mechanism, using POST to upload binary
objects to an Atom enabled server. This is the most common use case for a
mobile user.

When subsequent editing/replacing of an existing binary object
requires a SOAP envelope, base64 encoding and gzipping it all on MIDP then
I could possibly be OK with that too, since like you say this is indeed an
infrequent action.

I'll try to do some on device benchmarking for base64/gzip
action this weekend. Running code and all that.

> Now, the thought process
behind that question.
> 
> I don't want Atom to have to cater to the least
common denominator.  

I see MIDP enabled Atom clients as possibly the largest
Atom user base. So, I do see value in this group trying to cater to MIDPs
needs. 

If we can make sure that most of the basic Atom operations can
be executed by a Midlet, I'm a happy puppy.

> If someday we see a need
for the WebDav LOCK method, I would like to be 
> able to consider it without
having to worry about it being blocked or 
> eaten by some legacy gateway.

When that LOCK method is just required for some additional functionality,
that's fine. When it is required to do most of the basic stuff, it's not.

> And, on the other hand, I don't want whatever XML POST fallback we 
> decide on to be evolved randomly and in the same way that most gateways

> seem to have been - by sampling actual usage and reacting to complaints.

> 
> HTTP seems to go well beyond the 80/20 point.  Enough so that there

> really should only be one fallback, not a separate one for web services,

> another one for cell phones, and another one for whatever.
> 
> Therefore,
I'd like the fallback to be comprehensive - a 1 to 1 and onto 
> mapping
of requests that can be done - methods, auth, the works.  I'd 
> also like
the fallback to be considered in much the same way as HTTP 
> stacks treat
content-transfer-encoding: something that may be necessary 
> to achieve
the transfer across a given gateway, but not something that 
> conveys any
additional signal or state to the target application.
> Net: if the servers
implement the fallback mechanism as a simple mapping 
> onto the primary
mechanism, and then process the request as if they had 
> received the primary
form; then clients should be able to mix and match 
> with impunity.

> To take a concrete example: there will be a sleek and simple way to do
a 
> DELETE.  If for some reason you find that you can't use it, you are

> provided with an alternative.  The amount of bloat in the alternative
is 
> non-negotiable: if you don't like it, fix your gateway.  We picked
the 
> most popular protocol on the planet and provided a fully functional

> fallback: I believe that more than qualifies as going above and beyond

> the call of duty.
> I suspect that most people who can't use the primary
mechanism defined 
> for DELETE will not complain too loudly, as the overhead
of the fallback 
> in this case is constant, and the usage profile of this
operation is 
> relatively small.
> 
> With this background in place, the
more general form of the question 
> above is whether there is ANY operation
for which BOTH the primary AND 
> fallback defined are untenable for any
given client and usage profile?

I was just a bit worried about the
direction this WG has taken recently. It used to be all about Bob (and Alice)
and interoperability. Recently I have noticed voices which want to remove
WSSE, SOAP alternatives from the spec (at least normative) and introduce WebDav
methods to get a feed index.
 IMHO this negatively impacts operability.

Your message provides me with enough confidence that this will not happen.

Thanks,

Peter

---

From: [email-masked]
Date: 16 Jul 2004 15:21:35 -0000

--- Tim Bray <[email-masked] wrote:
Thanks for your recent contributions
to Atom Syntax; they have been 
> very helpful.  Perhaps you'd like to introduce
yourself to the group?

Ok, my name is Peter Mortier.

I'm a consultant/contract
programmer living and working in Belgium. I have been dabbling in Java since
1996. I've worked on everything from desktop applications (J2SE) to servers
(J2EE) and since 1999 also mobile phones (J2ME/MIDP), then known as KVM.

I have been lurking on this mailing list since it's started and finally
managed to decloack.

If your wondering about the strange e-mail address:
I'm subscribed to this mailing list through Bloglines, which provides me the
benefits of not having to worry about spam and being able to track this very
active mailing list in my preferred aggregator.

Regards,

Peter