Subject: Re: PacePutDelete Withdrawn

From: [email-masked]
Date: 16 Jul 2004 09:16:47 -0000

--- Joe Gregorio <[email-masked] wrote:

> I'm not familiar with
either MIDP or CDLC, could 
> you explain a little of what they are and their
relation
> to the underlying HTTP protocol?
> 

MIDP stands for Mobile
Information Device Profile and runs on top of CLDC (Connected Limited Device
Configuration). The CLDC defines a GCF (Generic Connection Framework) that
provides an API to communicate with the outside world (sockets, http, comm,
...). The MIDP running on top of CLDC defines and constrains the type of connections
possible for MIDP compatible devices. For MIDP 1.0 the only required connection
is HTTP and the only required methods to support are GET, HEAD and POST.

The reason why MIDP only allows for HTTP is simple: some phones run on networks
which don't have a native TCP/IP stack. These networks can still provide for
HTTP connectivity, by using the WSP (Wireless Session Protocol) stack, provided
by the WAP browser. WSP provides a HTTP mapping on top of most physical networks.

WSP has support for arbritrary HTTP methods (OPTIONS, PUT, DELETE, ...).
But because the main user of WSP stack is a WAP browser and this only ever
uses GET and POST, you can only rely on these two methods two work reliably.
Support for other methods on both phones and WAP gateways is very shaky. 

This is most likely the reason why the JSR expert group, which defined
MIDP, only required HTTP support and only mandated support for GET, HEAD and
POST.

>
> > The alternative as it is now is to use SOAP via POST, which
because of
> > the resource constraints on mobile devices is problematic:
Processing
> > power, storage and network speeds are all limited.
> > 

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

---

From: Sam Ruby <[email-masked]>
Date: Fri, 16 Jul 2004 07:29:25 -0400

> 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.

Now, the thought process behind that question.

I don't want Atom to have to cater to the least common denominator.  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.

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?

- Sam Ruby

---

From: Janne Jalkanen <[email-masked]>
Date: Fri, 16 Jul 2004 14:53:25 +0300

> relatively infrequent operation.

It is infrequent for binaries on a cell phone.  I think we can live 
without it.  You can't put a very big editor inside a J2ME application 
anyway.

PaceExtendedResourcePosting uses POST to send the binaries, so it should 
be safe.

But *requiring* the use of gzip/base64 is a big no-no.

> I don't want Atom to have to cater to the least common denominator.  
> 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.

Me neither.

> 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.

I'd still go for putting the "action" in a header, simply because that 
would not assume that the transported entry is XML (as in case with a 
resource PUT).

/Janne

---

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

> But *requiring* the use of gzip/base64 is a big no-no.

I am suggesting the requirement to *either* use HTTP method PUT *or* to 
base64 the content in the scenario of replacement.

I've never heard of anybody suggesting the requirement of gzip, but I 
have heard it mentioned as a potential way for trading bandwidth 
problems for battery life problems.

For those who have not ever had the opportunity to talk to an engineer 
from a cell phone manufacturer, I highly recommend it.  It gives you an 
interesting perspective.  You gain an newfound appreciation for the laws 
of thermodynamics, which when applied here boil down to:

   Every time you flip a bit, you generate heat, and drain your battery.

- Sam Ruby

---

From: Joe Gregorio <[email-masked]>
Date: Fri, 16 Jul 2004 09:05:29 -0400

On 16 Jul 2004 09:16:47 -0000, [email-masked]
<[email-masked]> wrote:
> which don't have a native TCP/IP stack.

Which is fine since HTTP isn't defined to run over TCP/IP.

> These networks can still provide for

I was following along up until here. I'm thinking of a wire trace 
of an HTTP session and I'm having trouble understanding
how different methods could be problematic. I am surely 
missing something here.

    Thanks,
    -joe