Subject: Re: PacePutDelete Withdrawn

From: [email-masked]
Date: 16 Jul 2004 19:59:50 -0000

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

> I would be concerned
that you could not POST arbitrary mime-types including binary content without
it being restricted to mulit-part mime.
> Is this a concern?

In my experience
this is not a problem.

I'll try to explain:

WSP encodes/decodes HTTP
requests into/from a binary format, called a PDU (protocol data unit). 
It
works by converting some "well known values" to binary tokens. Examples: the
HTTP GET method is represented as 0x40, a HTTP response code of 200 as 0x20
and mime-type text/html as 0x02. In the case of HTTP methods the list of possible
values is limited. Only GET, POST, HEAD, DELETE, OPTION, TRACE and PUT have
a binary counterpart.
In the case of content-type, "unknown values" can still
be encoded as a char sequence.
Aditionally the WapForum also defines conformance
levels [1] for client (phone) and server (gateway) implementations: only GET
and POST are required, all the others methods are optional. 

WebDav's PROPFIELD
will be guaranteed not work, while any arbitrary content-type can be transported
over WSP.

HTTP-over-WSP connectivity is the standard for mobile 2G networks
(f.e. GSM-CSD).
2.5 G (GPRS, EDGE) and 3G support native TCP/IP.

My Nokia3650
supports GSM-CSD and GPRS. I can define different access points: one using
GSM CSD and providing HTTP-over-WSP connectivity, the other using GPRS and
provide TCP/IP connectivity.

A native C++ application on my Nokia will
not be able to support WebDAV when I'm using my WAP access point.

I guess
the MIDP JSR expert group took a least common demoninator approach and somehow
came up with requiring support for only GET, HEAD and POST.

This does not
forbid MIDP licencees to implement support for additional HTTP methods, but
AFAIK this has not happened.

--
Peter

---

From: Robert Sayre <[email-masked]>
Date: Fri, 16 Jul 2004 19:22:45 -0400

> came up with requiring support for only GET, HEAD and POST.

According to PutDeleteSupport on the wiki, the following platforms have
problems:

- PHP prior to 4.3
- ColdFusion prior to 6.1
- Ruby Net::HTTP 
I don't have anything to say about these three.

- Python urllib2
Doesn't matter. httplib is easy and standard. Batteries included.

- Mac OS X - NSURLConnection
PUT requests omit the request body. I gather this bug is already fixed for a
future release. At any rate, OS X developers have plenty of other options
for HTTP connectivity.

- Java J2ME MIDP 1.0/2.0
I decided to ignore Peter and try writing something with PUT/DELETE.
Unsurprisingly, Peter was right. The upside is that I found that writing
text-based J2ME apps to be rather more convenient than I expected. So
convenient that we should make sure it's easy. It's pretty cool. I'm sure it
gets exponentially more difficult as you attempt to support more phone
models, but everything worked as expected on my Nokia 3650, the Sun
reference emulator, and a couple different Nokia emulators.

Unless your phone/network supports the "socket://" URI scheme, there's no
way you're going get at that OutputStream to set the HTTP method to PUT or
DELETE, unless you resort to monkey business that we should never recommend.

It would appear that the most convenient approach for J2ME applications
would be a request header in combination with POST. SOAP would be workable
as well, but updates of binary resources would be a problem.

- Flash
Flash MX 2004 / FlashPlayer 7 has SOAP support, and I'm pretty sure there's
nothing interesting you could send as binary with Flash. Headers are also
out, I think. The wiki mentions the XMLSocket object, which does let you
send anything over a socket (not just XML). It's restricted to the same host
and ports above 1024. Other Flash objects allow transmission of XML to port
80 on the same host. The LoadMovie() function allows loading of SWFs and
JPGs (JPGs in Flash6) from other hosts.

SOAP would appear to be the best bet here.

Note: I have written tons of ActionScript, but most of it was targeted at
Flash 5.

- Existing SOAP infrastructure
I'm guessing SOAP would be most convenient here ;)

Robert Sayre

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Fri, 16 Jul 2004 16:58:47 -0700

Another data point, from a Brew person at Qualcomm:

>It looks like Brew supports PUT & DELETE. You can use the Brew HTTP 
>implementation for what ever HTTP method you want. Don't know if 
>there's some extra stuff required for PUT & DELETE though. If so, 
>then it is probably not there (didn't see it in the source), but you 
>could probably make it work in some form. The HTTP engine is pretty 
>flexible. You can find some details on it in the Brew SDK API 
>Reference manual. The correct section is IWeb and the option is 
>WEBOPT_METHOD.  Am pretty sure you have to download the SDK to get 
>the documentation. You can get it at 
>https://brewx.qualcomm.com/brew/sdk/download.jsp.
>
>For Brew in general you can write most any program you want, so even 
>if Brew didn't support it you could write your own HTTP engine with 
>it. Brew makes an equivalent of sockets available. Phones are moving 
>from the ARM7 processor to the ARM9 processor now and that gives you 
>lots and lots of cycles. They also have a lot more memory than they 
>used to. Brew does SSL without any special hardware and it performs 
>OK on the ARM7 and well on the ARM9. I doubt your protocol is more 
>complex than SSL so in principle it is no problem. Mostly a matter 
>of access to sockets if the HTTP engine doesn't do PUT/DELETE.

--Paul Hoffman, Director
--Internet Mail Consortium

---

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

> Doesn't matter. httplib is easy and standard. Batteries included.

httplib is easy, standard, and less functional than urllib2:

http://www.intertwingly.net/blog/2003/09/02/AtomDigest-via-urllib2

Net: with Python out of the box, you get a choice.  Most relevant to 
Atom is that you get to chose a library which supports PUT or you can 
chose a library which supports HTTP Digest.  VERY annoying.

- Sam Ruby

---

From: Tim Bray <[email-masked]>
Date: Fri, 16 Jul 2004 20:43:38 -0700

On Jul 16, 2004, at 4:22 PM, Robert Sayre wrote:

> would be a request header in combination with POST.

Here's another simple way:

1. Create an entry:
POST the <atom:entry> to the feed EditURI

2. Update an entry:
POST the <atom:entry> to the feed EditURI
with one extra attribute update="URI of entry"

3. Delete an entry
POST to the feed editURI
<atom:delete entry="URI of entry" />

  -Tim

---

From: Ken MacLeod <[email-masked]>
Date: 16 Jul 2004 22:50:27 -0500

Tim Bray <[email-masked]> writes:

> > It would appear that the most convenient approach for J2ME
> > applications would be a request header in combination with POST.
> 

I don't think (2) would work for non-Atom-entry resource
representations, like image/jpeg, without using an XML wrapper and
base64.

  -- Ken

---

From: Joe Gregorio <[email-masked]>
Date: Sat, 17 Jul 2004 00:03:24 -0400

> <atom:delete entry="URI of entry" />

Just a point of clarification, and not to suggest
that I support this idea, which I don't,  but in the current 
spec there is a seperate EditURI for each
entry that could be edited, thus the 
attributes for "URI of entry" are not needed.

   -joe

---

From: Tim Bray <[email-masked]>
Date: Fri, 16 Jul 2004 21:18:03 -0700

> attributes for "URI of entry" are not needed.

That neatly solves the problem that Ken McLeod pointed out:

2. Update an entry:
POST the new content to the entry's EditURI

  -Tim

---

From: Joe Gregorio <[email-masked]>
Date: Sat, 17 Jul 2004 00:22:39 -0400

> POST the new content to the entry's EditURI

Oh. In my implementation I was going to make 
the EditURI for an entry the 
PostURI for comments on that entry.

   -joe

---

From: Martin Duerst <[email-masked]>
Date: Sun, 18 Jul 2004 18:44:24 +0900

>HTTP-over-WSP connectivity is the standard for mobile 2G networks

This is an overstatement. I'm not at all an expert in this area,
but I know for sure that most Japanese phones (2G or otherwise)
don't use WAP at all. And there are lots of mobile phones with
HTTP and HTML support in Japan.

Regards,     Martin.

---

From: [email-masked] (John Panzer)
Date: Sun, 18 Jul 2004 09:35:31 -0700

Robert Sayre wrote:

> ...
Is an X-ATOM-xxx HTTP request header a reasonable 90% solution?  This 
would work for both Atom XML and binary resources, is implementable even 
by CGI scripts on the server side, and I'm guessing has a nice simple 
specification (if present, overrides the HTTP method used in the 
original request).

>Note: I have written tons of ActionScript, but most of it was targeted at
We've used XML documents (non-SOAP) with Flash fairly successfully in a 
number of applications, for both reading and for posting (just GET and 
POST, though).  Not sure what underlying objects/libraries are being 
used, though I could find out if there is interest. 

It is possible to get around the same-host security restrictions via 
"crossdomain.xml" files placed at the root of the Atom server.  If a 
domain is listed in this file, Flash .swf files originally loaded from 
that domain are allowed to at least GET/POST to/from the Atom server.

Most of the time, Flash .swfs are served up from either the same host or 
well-known partner hosts, so a static crossdomain.xml file works.  There 
are some annoying differences between Flash 5/ Flash 6 w.r.t. security 
but I can't remember what they are at the moment.

-John Panzer

Example /crossdomain.xml:

<cross-domain-policy>
<allow-access-from domain="*.aol.com"/>
<allow-access-from domain="channelevents.aol.com"/>
<allow-access-from domain="*.channel.aol.com"/>
</cross-domain-policy>

---

From: Robert Sayre <[email-masked]>
Date: Sun, 18 Jul 2004 13:00:16 -0400

> specification (if present, overrides the HTTP method used in the

I think the Header and/or SOAP/XML are reasonable 90% solutions. Both of
them make me squeamish, but that's life. The binary requirement is for a
proposal we haven't accepted yet. I think we should keep our options open
for now. 

> used, though I could find out if there is interest.

Yep, it works pretty well. It's called the "XML Object" [1]. You can use GET
(XML.load()) or POST (XML.sendAndLoad()) with it.

You assign a callback function to the object before you send the request.
When it's all loaded, you get a DOM-style interface to the data.

> that domain are allowed to at least GET/POST to/from the Atom server.

I was surprised to see this. I'd never heard of it. It seems to be a feature
of FlashPlayer 7 only [1]. Is that right?

Robert Sayre

[1] 
http://www.macromedia.com/support/flash/action_scripts/actionscript_dictiona
ry/actionscript_dictionary827.html

[2] http://www.macromedia.com/devnet/mx/flash/articles/fplayer_security.html

---

From: [email-masked] (John Panzer)
Date: Sun, 18 Jul 2004 11:16:19 -0700

>[2] http://www.macromedia.com/devnet/mx/flash/articles/fplayer_security.html
I do dimly recall that we had to do something different for Flash 6 and 
7, with F7 being much easier to deal with.  I've identified the internal 
guru on this and I hope to have details on Monday.

John

---

From: [email-masked] (John Panzer)
Date: Sun, 18 Jul 2004 11:33:19 -0700

Robert Sayre wrote:

>them make me squeamish, but that's life. 
>
Yes, me too.

>The binary requirement is for a
I agree in principle.  (But does this mean that we should refrain from 
adopting something incompatible with possible future binary HTTP requests?)

-John

---

From: Russell Beattie <[email-masked]>
Date: Sun, 18 Jul 2004 12:29:06 -0700

John Panzer wrote:

> would work for both Atom XML and binary resources, is implementable 
> even by CGI scripts on the server side, and I'm guessing has a nice 
> simple specification (if present, overrides the HTTP method used in 
> the original request).
>

I think it's great. I suggested an X-ATOMACTION header back in Februrary 
[1] and I still like the idea:

> One solution is to add another custom HTTP header. Since we have to do 
> that anyway for the WSSE security this may not a bad idea, it would 
> have the benefit of allowing the server process to not worry about XML 
> until it had to. Apache might even have a mod_rewrite rule for the 
> EditURI which looks for POSTs with an Action header which could change 
> the request's verb on the fly so the backend wouldn't even have to be 
> modified.

I think this garnered some support among some others as well.

- Russ

[1] http://www.imc.org/atom-syntax/mail-archive/msg03025.html

---

From: Don Park <[email-masked]>
Date: Sun, 18 Jul 2004 17:09:37 -0700

3. Delete an entry
POST an entry with empty content to the entry's EditURI

Don

---

From: Janne Jalkanen <[email-masked]>
Date: Tue, 20 Jul 2004 16:37:55 +0300

> simple specification (if present, overrides the HTTP method used in 

I think it is.  I took the alternate solution from PacePutDelete and 
codified it as a new Pace.

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

/Janne

---

From: Joe Gregorio <[email-masked]>
Date: Tue, 20 Jul 2004 10:23:56 -0400

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

Looks good, but would you mind removing the
WSSE headers from the examples so we don't 
accidently conflate the two issues of 
authentication and the Action header?

    Thanks,
    -joe

-- 
Joe Gregorio        http://bitworking.org

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Tue, 20 Jul 2004 07:34:01 -0700

And yet another data point, this time from Symbian:

>Symbian OS HTTP requests support all the methods in RFC 2616 
>(OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, CONNECT).
>These are available in the public API, so anyone can write an 
>application to phone can use them.

--Paul Hoffman, Director

---

From: Sam Ruby <[email-masked]>
Date: Tue, 20 Jul 2004 10:39:34 -0400

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

Are we *SURE* that there are *NO* gateways that "eat" headers?

I do not want to have multiple "fallbacks".

HTTP is a reasonable 90% solution - most clients have full support, and 
most of the rest have adequate support for the most common operations.

- Sam Ruby

http://www.imc.org/atom-syntax/mail-archive/msg07173.html
http://www.imc.org/atom-syntax/mail-archive/msg07178.html
http://www.intertwingly.net/wiki/pie/DifferentlyAbledClients

---

From: Robert Sayre <[email-masked]>
Date: Tue, 20 Jul 2004 11:17:01 -0400

Sam Ruby wrote:

> Janne Jalkanen wrote:
>
>>> Is an X-ATOM-xxx HTTP request header a reasonable 90% solution?  
>>> This would work for both Atom XML and binary resources, is 
>>> implementable even by CGI scripts on the server side, and I'm 
>>> guessing has a nice simple specification (if present, overrides the 
>>> HTTP method used in the original request).
>>
>>

Yeah, we are bending over backwards for the one client platform we can 
find that can set headers, but not the request method. This doesn't help 
Flash or existing SOAP software.

Since this method is preferable to SOAP for binary resources, and the 
Pace lists support for Atom-Action as a MUST,  how would one use this 
method to PUT or DELETE a .jpg file on a server that can run only CGI 
scripts? I think this would require mod_actions access for an Apache 
account. In Appendix A of the APP draft, SOAP Enabling and support for 
the SOAPAction header are a SHOULD.

The SOAP 1.2 HTTP binding[0] would seem to solve all of the problems 
this Pace does, with the exception of binary PUT uploads. Would it be 
acceptable to require base64 for the infrequent case of editing on a 
cell phone? It seems reasonable to assume that cell phone clients will 
mostly be POSTing, and that mobile platforms that are somewhat pleasant 
to use for editing are more likely to have the ability to PUT.

Robert Sayre

[0] http://www.w3.org/TR/2003/REC-soap12-part2-20030624/#soapinhttp

---

From: Joe Gregorio <[email-masked]>
Date: Tue, 20 Jul 2004 11:53:41 -0400

On Tue, 20 Jul 2004 11:17:01 -0400, Robert Sayre <[email-masked]> wrote:
> find that can set headers, but not the request method. 

We are bending over backwards for clients that do
not fully support HTTP, which is questionable 
given our charter.

> This doesn't help

How does this not help Flash, can Flash not set headers?
I thought it's only problem was lack of PUT and DELETE.

> scripts? 

What does binary have to do with cgi scripts?

    -joe

---

From: Robert Sayre <[email-masked]>
Date: Tue, 20 Jul 2004 12:02:59 -0400

>I thought it's only problem was lack of PUT and DELETE.
My mistake. Flash Player v6 and later can set them.

>What does binary have to do with cgi scripts?

How could something like Movable Type support the following?

POST /images/foo.jpg HTTP/1.1
Content-type: image/jpg
Atom-Action: PUT

Robert Sayre

---

From: Robert Sayre <[email-masked]>
Date: Tue, 20 Jul 2004 12:07:40 -0400

> My mistake. Flash Player v6 and later can set them.

doh! My mistake again. This capability was added in minor revisions to 
Flash Player 6:

Windows and Mac Classic: version 6.0r65
Mac OS X: version 6.0r67
Linux: version 6.0r69

Robert Sayre

---

From: Sam Ruby <[email-masked]>
Date: Tue, 20 Jul 2004 12:16:41 -0400

> POST /images/foo.jpg HTTP/1.1

The following environment variables would be set:

   REQUEST_URI=/images/foo.jpg
   CONTENT_TYPE=image/jpg
   HTTP_ATOM_ACTION=PUT

image itself would be available as stdin

  - - -

If we, as a group, decide we don't need no steenken fallback, I would be 
willing to go along with the consensus.  I wouldn't be happy, but I 
would go along with it.

But, if we decide that we need do need a fallback, then I believe that 
we should seek the one that has the widest possible coverage and makes 
the fewest possible assumptions as to what a client/gateway combination 
would support.

- Sam Ruby

---

From: Mark Baker <[email-masked]>
Date: Tue, 20 Jul 2004 12:28:50 -0400

> Are we *SURE* that there are *NO* gateways that "eat" headers?

Ironically, an early version of the RIM Blackberry Enterprise Server
(circa spring 2002, IIRC) ate extension headers.  It was fixed shortly
after we (Idokorro) reported the problem.  I don't know how well
deployed it was, but I suspect not very.

Mark.

---

From: Robert Sayre <[email-masked]>
Date: Tue, 20 Jul 2004 12:28:10 -0400

> image itself would be available as stdin

But wouldn't the ability to redirect PUTs and DELETEs to a CGI require a 
degree of control over the server that we haven't previously required?

I guess I'm confused how the edit endpoint for a binary resource would 
be configured. Would binary resources have their own EditURIs?

Robert Sayre

---

From: Tim Bray <[email-masked]>
Date: Tue, 20 Jul 2004 09:46:32 -0700

> not fully support HTTP, which is questionable

[me, not the co-chair] The notion that we would even think of shipping 
a protocol designed for use by (among others) bloggers that is not 
usable on the world's most popular smart-phone system seems ludicrous 
on the face of it, to me.  -Tim

---

From: Tim Bray <[email-masked]>
Date: Tue, 20 Jul 2004 09:55:25 -0700

On Jul 20, 2004, at 9:28 AM, Robert Sayre wrote:

> But wouldn't the ability to redirect PUTs and DELETEs to a CGI require 
> a degree of control over the server that we haven't previously 
> required?

Pretty straightforward on Apache they tell me, not really any harder 
than catching GET/POST. -Tim

---

From: Sam Ruby <[email-masked]>
Date: Tue, 20 Jul 2004 13:14:10 -0400

Tim Bray wrote:
>> a degree of control over the server that we haven't previously required?
> 

Any Apache CGI that can recieve a POST can also recieve a PUT.  They 
simply need to check the "REQUEST_METHOD" in order to distinguish 
between the two.

- Sam Ruby

---

From: Robert Sayre <[email-masked]>
Date: Tue, 20 Jul 2004 13:24:07 -0400

Sam Ruby wrote:

>>> But wouldn't the ability to redirect PUTs and DELETEs to a CGI 
>>> require a degree of control over the server that we haven't 
>>> previously required?
>>
>>

I phrased my question badly, but note that I wrote *redirect*. What does 
it take to serve a .jpg file on a GET, while directing POSTs, PUTs, and 
DELETEs to a CGI? This is an issue Atom entries don't encounter, because 
they can specify an EditURI. If the server user has somewhere to stick a 
"Script" directive, it's no problem:

Script PUT /~bob/put.cgi

Does a standard shared hosting account allow the following?

This request would go to a CGI specified in a "Script" directive:
PUT /images/foo.jpg HTTP/1.1
Content-type: image/jpg

This request would just serve the file:
GET /images/foo.jpg HTTP/1.1

Robert Sayre

---

From: Sam Ruby <[email-masked]>
Date: Tue, 20 Jul 2004 13:35:36 -0400

Robert Sayre wrote:
> DELETEs to a CGI?

I'll answer a question with a question, then.  Why is a redirect 
required?  If you find that you can't do a redirect, you can simply 
serve the GET via your CGI, thus:

   #!/usr/bin/python
   print "Content-type: image/jpg\r\n\r\n" + open("foo.jpg").read()

- Sam Ruby

---

From: Joe Gregorio <[email-masked]>
Date: Tue, 20 Jul 2004 13:41:16 -0400

> GET /images/foo.jpg HTTP/1.1

if os.environ["REQUEST_METHOD"] == "GET":
    print "Content-type: image/jpg\r\n\r\n"
    f = file("foo.jpg", "r")
    os.stdout.write(f.read())
elif  os.environ["REQUEST_METHOD"] == "PUT":
    f = file("foo.jpg", "w")
    f.write(os.stdin.read())
    f.close()

    -joe

---

From: Robert Sayre <[email-masked]>
Date: Tue, 20 Jul 2004 13:49:57 -0400

>elif  os.environ["REQUEST_METHOD"] == "PUT":

OK. Both of these answers imply an EditURI for binary resources, 
correct? I don't think I would want to include the CGI output in my 
feed. I would rather use the static resource (e.g. <img src="foo.jpg">). 
Is the relationship between the static resource and the EditURI one we 
want to make explicit?

Robert Sayre

---

From: "John Panzer" <[email-masked]>
Date: Tue, 20 Jul 2004 11:07:01 -0700

> be configured. Would binary resources have their own EditURIs?

I think that for binary resources, the EditURI needs to be the same as 
the ResourceURI (that is, the same URI needs to accept both GET and, if 
supported, PUT/DELETE).  This is the assumption in 
PaceSimpleResourcePosting and it's not in conflict with 
PaceNonEntryResources.

Reasoning:  For the most common use case, the way to find a URI for a 
non entry binary resource is to parse (X)HTML and look for things like 
<img @src="..."/>.  Clearly this is the ResourceURI used for GETs. 
Given that URI, then, how do you discover the EditURI to use for 
PUTs/DELETEs?  The simplest way is to assume EditURI = ResourceURI.

-John Panzer

---

From: Ken MacLeod <[email-masked]>
Date: 20 Jul 2004 13:08:25 -0500

Robert Sayre <[email-masked]> writes:

> feed. I would rather use the static resource (e.g. <img
> src="foo.jpg">). Is the relationship between the static resource and
> the EditURI one we want to make explicit?

Just so I'm clear, are we confusing the "public" GETable URI for the
resource for reading clients with the "private" EditURI intended for
editing clients?

The EditURI supports GET/PUT/DELETE.  The public URI supports GET.
Those URIs could be the same, if that's how one's publishing system
works, but they don't need to be.

A redirect from the "public" URI to the EditURI isn't necessary.

  -- Ken

---

From: "John Panzer" <[email-masked]>
Date: Tue, 20 Jul 2004 10:35:11 -0700

> GET /images/foo.jpg HTTP/1.1

In the absolute worst case, the CGI script can stream the bits of the 
JPG image back to the client when it sees the GET.  So in the edge case 
where you can't use "Script" or its moral equivalent, there is an 
(inefficient) workaround.  I'd assert this is sufficient, but perhaps 
I'm missing something?

-John

---

From: "John Panzer" <[email-masked]>
Date: Tue, 20 Jul 2004 11:32:24 -0700

> works, but they don't need to be.

Please see my earlier post on this thread, though, for an argument as to 
why EditURI should be the same as the "public" GETable URI for binary 
resources.  Although this is a restriction on what publishing systems 
are allowed to do, I think it's a reasonable restriction that enables 
important functionality, namely, discovering the EditURIs of non entry 
resources associated with a referring atom:entry.

I believe that one rationale for separating the EditURI and "public" 
GETable URI for Atom entries is that the two may have different content 
representations, e.g., for Wiki text that maps to publicly viewable 
HTML.  Is there a use case for this in the case of binary resources? 
That's about the only reason I can think of for a publishing system 
_not_ making the URIs the same.

(In which case, I would ask whoever comes up with that use case also 
give a proposal for how to map from the "public" GETtable URI to the 
EditURI.  In the case of atom:entries, this is easy using a <link> 
construct.  For binary resources, this doesn't work.  So what's the 
alternative?)

-John Panzer

---

From: Ken MacLeod <[email-masked]>
Date: 20 Jul 2004 14:15:56 -0500

"John Panzer" <[email-masked]> writes:

> GETable URI for Atom entries is that the two may have different
> content representations, e.g., for Wiki text that maps to publicly
> viewable HTML.  Is there a use case for this in the case of binary
> resources?  That's about the only reason I can think of for a
> publishing system _not_ making the URIs the same.

Use Case #1: Serving static files from the web server directly.  The
benefits are many: proper headers, performance, no locking on large
requests (PCGI is single threaded, for example), etc.

Use Case #2: Output resources served from a different host than the
editing system.

I think both of these are significant cases in current practice.

> construct.  For binary resources, this doesn't work.  So what's the

Two alternatives:

1) Do nothing.  If the user is cutting-n-pasting the URL of an <entry>
   output web page so the client can autodiscover the <link> to the
   EditURI, the user can cut-n-pasted the URL of the resource from the
   publishing system's "list resources" page that lists editable
   resources.

2) Include the resources in the Atom index "feeds" (the "feeds" used
   by the editing clients to index posts no longer in the dynamic
   feed).

   PaceExtendedResourcePosting specifies adding a "full" metadata
   wrapper for non-entry resources, but a "minimal" metadata wrapper
   can be provided by the system.

  -- Ken

PS. Third alternative:  WebDAV PROPFIND ;)

PPS. It might also be politically incorrect in Atom circles to
consider that the ResourceBaseURI might be an FTP URL, but in that
situation the alternative is FTP's LIST command.  I wonder if there
aren't already editing clients that support FTP servers?

---

From: "John Panzer" <[email-masked]>
Date: Tue, 20 Jul 2004 14:02:52 -0700

> requests (PCGI is single threaded, for example), etc.

(Aside: Should we be worried about optimizing the performance of CGI 
based servers?)  I think this is a valid point, but it might be an edge 
case (most servers capable of high volume static file GET requests can 
fairly easily shunt low volume PUT/DELETE requests to other code, IMHO.)

 > Use Case #2: Output resources served from a different host than the

This one I have some sympathy for.  But I do wonder if there are really 
existing systems where a high-volume server farm is set up for binaries, 
where the provider wants to support PUT/DELETE as well as creation for 
said resources, and where the high-volume server farm cannot reasonably 
also support PUT/DELETE.  Is this in the 80% of cases we should worry about?

 >    publishing system's "list resources" page that lists editable

I'm not sure I understand the above.

Here's my use case:  I retrieve the Atom entry using the Atom API with 
the intent of editing it; presumably I use a GET to whatever URI returns 
the 'editable' or 'native' content in order to do this (EditURI?).  I 
then display it in my WYSIWYG editor, which renders the picture of my 
cat inline based on the XHTML content: <img 
src="http://example.org/cat1.jpg"/>.  I then drag a better cat picture 
on top of the original, and save the entry.  My client sees that I have 
only made a change to the picture, and decides to automatically replace 
the old picture.  How does it do this?

Some suggestions:
(1) Assume EditURI == "public" GET URI.  No problems.
(2) When the atom:entry is retrieved in 'edtiable' mode, the 
atom:content data refers to the _resource_ 'editable' URLs as well. 
That is, instead of <img src="http://example.org/cat1.jpg"/> you see 
<img src="http://edit.example.org/res/cat1.jpg"/>, and then this 
devolves just to suggestion (1).
(2) Provide metadata on the "public" GET URI via HTTP headers.  Requires 
an extra HEAD request to get metadata, followed by a PUT to the 
retrieved resource EditURI.  Also requires server to support metadata on 
every GET request.
(3) Give up on mapping from entries to associated resources.  Don't 
support updating pictures as discovered via entries.
(4) Why do you even care about this?

 >    by the editing clients to index posts no longer in the dynamic

Sure, but this doesn't help relate the resources to the individual 
entrie(s) they're associated with.  That's a use case I'm interested in; 
do you think this isn't useful?

 >    can be provided by the system.

I don't have a problem with PaceExtendedResourcePosting as an option, 
but I don't think that it should necessarily be _required_ of servers.

Note that if the hypothetical binary resource server farm above can 
provide even a "minimal" metadata wrapper for non-entry resources on 
GETs... why couldn't it just as easily provide support for PUT and 
DELETE and be done with it?

 > PS. Third alternative:  WebDAV PROPFIND ;)

:) Of course if a server can support PROPFIND easily, could it support 
PUT and DELETE...? :)

 > aren't already editing clients that support FTP servers?

That would be an interesting use case -- non-HTTP editing of resources?

-John Panzer

---

From: Robert Sayre <[email-masked]>
Date: Tue, 20 Jul 2004 19:58:04 -0400

John Panzer wrote:

>fairly easily shunt low volume PUT/DELETE requests to other code, IMHO.)**
>  
>

The MetaWeblog API's newMediaObject[0] endpoint works with CGI, but it 
has problems when it comes to PUTing and DELETEing resources and it 
requires base64. Existing software expects this functionality. We should 
provide it and improve obvious deficiencies of current approaches.

Robert Sayre

[0] http://www.xmlrpc.com/metaWeblogApi#metaweblognewmediaobject

---

From: Ken MacLeod <[email-masked]>
Date: 20 Jul 2004 20:08:46 -0500

> This one I have some sympathy for.  But I do wonder if there are
> really existing systems where a high-volume server farm is set up
> for binaries, where the provider wants to support PUT/DELETE as well
> as creation for said resources, and where the high-volume server
> farm cannot reasonably also support PUT/DELETE.  Is this in the 80%
> of cases we should worry about?

In the context of this use-case, it's more likely that *all* published
resources are pushed to a static site, rendered HTML and binaries
alike.  Very common.

> Here's my use case: I retrieve the Atom entry using the Atom API
> with the intent of editing it; presumably I use a GET to whatever
> URI returns the 'editable' or 'native' content in order to do this
> (EditURI?).  I then display it in my WYSIWYG editor, which renders
> the picture of my cat inline based on the XHTML content: <img
> src="http://example.org/cat1.jpg"/>.  I then drag a better cat
> picture on top of the original, and save the entry.  My client sees
> that I have only made a change to the picture, and decides to
> automatically replace the old picture.  How does it do this?
> 
> Some suggestions:
> (2) Provide metadata on the "public" GET URI via HTTP headers.
> Requires an extra HEAD request to get metadata, followed by a PUT to
> the retrieved resource EditURI.  Also requires server to support
> metadata on every GET request.

I think we need to look at how current publishing systems work, and
provide a usable protocol for those that can work with it, rather than
mandate how they all must work.

(1) seems like the best possible level of support that we can spec in
the core.  (first #2) seems hackish, but doable; I'd suggest in an
extension.  (second #2) would require server support that may not be
possible in many cases where (1) would work anyway, so we should give
up on it.  (3) must be a consideration by clients *in any case*, that
some sites may not provide resource mapping, or that resources linked
from entries might not even be from the same publishing system!
(4) I care!

>  > 2) Include the resources in the Atom index "feeds" (the "feeds"
>  >    used by the editing clients to index posts no longer in the
>  >    dynamic feed).
>  >
> 
> entrie(s) they're associated with.  That's a use case I'm interested
> in; do you think this isn't useful?

Like (first #2) above, if a) you know the published resource location,
and b) have the index mapping the published resource location to the
EditURI, then you have both ends of that connection.

>  >    wrapper for non-entry resources, but a "minimal" metadata
>  >    wrapper can be provided by the system.
>  >
> 
> I don't have a problem with PaceExtendedResourcePosting as an
> option, but I don't think that it should necessarily be _required_
> of servers.
> 

Because those metadata wrappers can 1) be retrieved at separate URLs,
and 2) appear in index feeds (static or dynamic), neither of which
requires any server support beyond a static server.

> :) Of course if a server can support PROPFIND easily, could it support 

I meant PROPFIND on the editing server, for locating all the editable
resources.  WebDAV then also defines the "source" property for mapping
the source resource to the output resource, which could then be used
for (first #2) above -- if the editing server itself was not also the
publishing server, as in (1) above.

>  > consider that the ResourceBaseURI might be an FTP URL, but in
>  > that situation the alternative is FTP's LIST command.  I wonder
>  > if there aren't already editing clients that support FTP servers?
>  >
> 

LOL, you make that sound like a foreign concept rather than common
practice! :-)

  -- Ken

---

From: Joe Gregorio <[email-masked]>
Date: Tue, 20 Jul 2004 13:52:34 -0400

> elif  os.environ["REQUEST_METHOD"] == "PUT":

Or you can serve the file off the file system
and use a .htaccess to redirect on a PUT

RewriteEngine  on
RewriteCond  %{REQUEST_METHOD} POST [nc]
RewriteRule photos(/.*)?$   /photohandler.cgi$1               [last]

---

From: Joe Gregorio <[email-masked]>
Date: Tue, 20 Jul 2004 21:46:34 -0400

On Tue, 20 Jul 2004 14:02:52 -0700, John Panzer <[email-masked]> wrote:
> the old picture.

What if the user only wanted the new picture uploaded and 
the old picture left in place to be used in another post?
How about if the picture was resized, do you replace it then?
And what if a picture was added, how to you know if that
picture was already published or if it still needs publishing?

I could go on and on.

> (4) Why do you even care about this?

I don't. And I don't think we should spent time trying to 
figure out the 'right' way to do this. Let's just provide a protocol
for publishing "(X)HTML and/or plain text" entries along
with a way to publish binary content which may or may
not use the same mechanism. 

    -joe

---

From: Janne Jalkanen <[email-masked]>
Date: Wed, 21 Jul 2004 14:29:38 +0300

>authentication and the Action header?
Done.  I also added some discussions from the list into the Notes-section.

/Janne

---

From: Janne Jalkanen <[email-masked]>
Date: Wed, 21 Jul 2004 15:22:32 +0300

> that domain are allowed to at least GET/POST to/from the Atom server.

BTW, this reminds me of one drawback: if you want to protect your web 
service using method-based filtering (like using the security-constraint 
in J2EE web.xml files), you have to assume that DELETE, POST, and PUT 
have all the same access restrictions, because you don't know whether 
your client can support PUT/DELETE or not.

Which may be not what you want, but there you go anyway.  I would 
imagine that this is mostly not going to be a problem, though, as it 
only affects people who want container-based authentication.

/Janne

---

From: Janne Jalkanen <[email-masked]>
Date: Wed, 21 Jul 2004 15:34:45 +0300

> find that can set headers, but not the request method. This doesn't 
> help Flash or existing SOAP software.

I'm with Tim on this one; we're not bending over backwards (as in 
redesigning the entire protocol around one client platform), but just 
acknowledging the existence of a hundred million Java-enabled phones out 
there (don't quote me on the figure, I think it's in the ballpark, but I 
don't remember the official numbers :)

> mostly be POSTing, and that mobile platforms that are somewhat 
> pleasant to use for editing are more likely to have the ability to PUT.

Well, to me SOAP is the more dubious solution because it assumes things 
about the payload more than it should (payload always XML).  The 
Atom-Action header does not modify nor assume anything about the 
payload, and has thus less impact on both clients and the servers. It is 
also far simpler than bringing in SOAP.

And while most of our use cases don't assume editing on the cell phones, 
you can see at least in the japanese market that phones are already 
gaining image editing capabilities.  I would find it at least odd to 
make the life of third party developers more difficult just because they 
would like to have an Atom editing client.

Besides, with Wikis and other CMS systems, attachments might get edited 
far more often than with just plain weblogs (which are mostly of 
fire-and-forget) -type.

/Janne

---

From: Janne Jalkanen <[email-masked]>
Date: Wed, 21 Jul 2004 15:47:48 +0300

>fairly easily shunt low volume PUT/DELETE requests to other code, IMHO.)
Yup.  And with Atom-Action you are still retaining GET anyway.

>also support PUT/DELETE.  Is this in the 80% of cases we should worry about?
If blogging is to become über-popular, then possibly.  The binaries 
could be hosted on akamai or some other caching service more probably, 
though.  Then again, so would probably the feeds.

>(1) Assume EditURI == "public" GET URI.  No problems.
Possible.

>retrieved resource EditURI.  Also requires server to support metadata on 
This is what PaceExtendedResourcePosting is suggesting.  I think an 
extra HEAD for PUT is not that heavy.

And is it really required to support, say, a Meta-Location header for 
GET as well, if it's supported for HEAD?  I mean, if a blogging service 
has a dedicated binary server, they can churn out the GETs as much as 
they like, and whenever someone wants to know where the metadata for an 
image lies (mostly an editing client) it would fire off a HEAD.

>but I don't think that it should necessarily be _required_ of servers.
I agree.  It's rather easy to check whether metadata is supported: just 
check the existence of Meta-Location on the HEAD request.  If it's not 
there, you can't post metadata.

This would allow servers to support three levels of Atom API:

* Entries only  (Atom Core)
* Entries +binaries (If a ResourcePostURI is available)
* Entries + binaries + metadata (If a Meta-Location -header is available)

>:) Of course if a server can support PROPFIND easily, could it support 
Yup :)

/Janne

---

From: Janne Jalkanen <[email-masked]>
Date: Wed, 21 Jul 2004 15:50:21 +0300

>resources.  WebDAV then also defines the "source" property for mapping
Of course, this does not work on the resource constrained 
(PutDeleteBorked :) platforms, as discussed on the Other Thread. :)

/Janne

---

From: Janne Jalkanen <[email-masked]>
Date: Wed, 21 Jul 2004 15:56:10 +0300

>_not_ making the URIs the same.
I don't see how - binary is binary is binary.  If you want to offer a 
separate (like an image transforming service) you would figure out a 
different URI for each of the types you want to produce, and probably 
would not use Atom at all.  (But serve entries like 
http://example.com/png/image1 or http://example.com/jpg/image1).

For wikis, yes, it has to be assumed that you can GET the entry in two 
(perhaps three) forms: wikimarkup, rendered HTML and some hypothetical 
WikiML, and perhaps PUT them in all formats as well.  Which should be 
fun :-/

/Janne

---

From: Bill de hÓra <[email-masked]>
Date: Wed, 21 Jul 2004 15:12:38 +0100

> don't remember the official numbers :)

Here's a plausible counter argument. There'll be 10 times that many 
HTTP enabled devices in 3 years. In 3 years most of those 100M 
devices will have been thrown away. So this approach will be baking 
in a subset of HTTP for the short/medium term for what will be a 
miniority of phones. It's the next 900M phones running HTTP that 
need to be thought about.

cheers
Bill

---

From: Sam Ruby <[email-masked]>
Date: Wed, 21 Jul 2004 10:33:23 -0400

Bill de hÓra wrote:

> Janne Jalkanen wrote:
> 
>>> Yeah, we are bending over backwards for the one client platform we 
>>> can find that can set headers, but not the request method. This 
>>> doesn't help Flash or existing SOAP software.
>>
>> acknowledging the existence of a hundred million Java-enabled phones 
>> out there (don't quote me on the figure, I think it's in the ballpark, 
>> but I don't remember the official numbers :)
> 
> Here's a plausible counter argument. There'll be 10 times that many HTTP 
> enabled devices in 3 years. In 3 years most of those 100M devices will 
> have been thrown away. So this approach will be baking in a subset of 
> HTTP for the short/medium term for what will be a miniority of phones. 
> It's the next 900M phones running HTTP that need to be thought about.

You are both right... to a point.  There is a chicken and egg problem. 
People won't produce new phones with full support for HTTP until there 
are applications that demonstrate the value.

The first question we have to face is whether we want to design for the 
least common demoninator based on the facts as we know them today, or if 
we want to have a "primary" mechanism and one or more "fallbacks".

If we decide to go for least common denominator, we need to determine if 
we can rely on HTTP methods like DELETE and Atom specific HTTP headers.

If we decide to go for one or more fallbacks, we need to determine how 
many we are going to support.

The reality is that if we go for least common denominator now, there 
will be less motivation for cell phones to update, and even if they do, 
it will be hard to change the deployed base of Atom applications.

Even if we provide both a primary and fallback mechanism (with the 
primary having clear benefits in terms of bandwidth, etc), then there 
will be a period of time where it takes for Atom to get adopted widely, 
marketing to get the message, product designers to make the product, and 
for the new products to get widely deployed.

The option of ignoring a large class of existing cell phones entirely 
would severely affect the adoption of Atom and prevent this feedback 
loop from happening.

- Sam Ruby

---

From: Bill de hÓra <[email-masked]>
Date: Wed, 21 Jul 2004 15:41:46 +0100

> are applications that demonstrate the value.

Yeah, it's a classics standards adoption problem :) But I take it as 
a good sign that we have this problem.

 > [...]

Too true. Does that leave us looking for a "graceful upgrade" path 
based on client capabilities? I think it has to, but I don't know 
what that might be yet :)

cheers
Bill

---

From: Mark Baker <[email-masked]>
Date: Wed, 21 Jul 2004 12:07:52 -0400

> would severely affect the adoption of Atom and prevent this feedback 

I can't recall who it was, but somebody on IRC mentioned that we already
have a fallback mechanism; those clients that can't PUT or DELETE can't,
erm, PUT or DELETE stuff.  But they can still GET/HEAD/POST, which gives
them access to a lot of functionality.

Though I was supportive of Atom-Action, I kinda like this option too as
it seems to find a happy place in the feedback loop you mentioned, Sam.

Mark.

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Wed, 21 Jul 2004 09:04:49 -0700

At 10:33 AM -0400 7/21/04, Sam Ruby wrote:
>The first question we have to face is whether we want to design for 
>the least common demoninator based on the facts as we know them 
>today, or if we want to have a "primary" mechanism and one or more 
>"fallbacks".
>
>  . . .
>
>If we decide to go for one or more fallbacks, we need to determine 
>how many we are going to support.
>
>will be less motivation for cell phones to update, and even if they 
>do, it will be hard to change the deployed base of Atom applications.

Welcome to the IETF. And a big +1 to what Sam said. We have *lots* of 
experience with grappling with these kinds of questions, but with 
different constraints. And we have lots of experience with the 
results.

Basically: if we provide a fallback, the fallback will be with us 
forever, and adoption of the primary method will be slow, like 
probably a decade (think POP vs. IMAP).

>The option of ignoring a large class of existing cell phones 
>entirely would severely affect the adoption of Atom and prevent this 
>feedback loop from happening.

Maybe. Cell phones are still in the adoption phase, and there is a 
reasonable turnover in phones. If our protocol worked on some current 
cell phones but not others, the others would be improved in the 
future, certainly in a small number of years. Some people will not be 
able to use Atom in their current phones, but will be able to use it 
in the phones they will replace their current phones with.

In the short run, services will possibly appear that act as proxies 
for the less-enabled phones to do what the more-enabled phones can do 
by themselves. As long as our solution is proxyable, we won't be 
"excluding" anyone even in the short term.

Again, the alternative is that we need to support two protocols 
forever. More specifically, we need to support the less-able protocol 
forever. A possibly-better choice would be to go with the one 
protocol we really want, and have those not able to run it possibly 
proxy in the short run and be able to run it on their new phones 
within a small number of years.

--Paul Hoffman, Director

---

From: Joe Gregorio <[email-masked]>
Date: Wed, 21 Jul 2004 12:33:44 -0400

> them access to a lot of functionality.

That was me. I was in particular referencing our charter:

    The working group will also take steps to ensure interoperability, by:
    ...
    * clearly nominating conformance levels for different types of
        software

    -joe

---

From: Robert Sayre <[email-masked]>
Date: Wed, 21 Jul 2004 12:55:42 -0400

Paul Hoffman / IMC wrote:

> 
> Again, the alternative is that we need to support two protocols forever. 
> More specifically, we need to support the less-able protocol forever. A 
> possibly-better choice would be to go with the one protocol we really 
> want

This is a great argument against inventing our own fallback mechanism, 
like a custom header or <action> element. However, I'm not sure "the one 
protocol we really want" is a completely settled issue. I think the 
current SHOULD-level requirement for SOAP is a decent compromise, as 
there is demand for SOAP, especially on Intranets and other private 
networks. Existing implementations have implemented the SOAP fallback 
without much difficulty or duplication of infrastructure.

It may be that the SOAP solution will not have all the capabilities of 
the ReST one (e.g. PUT/DELETE on binary content), and that's ok, too.

I agree with Anil Dash:

"It may be that we're all so close to the deeply web-savvy part of the
software world that people who do all their coding in Visual Studio,
implementing SOAP services with a WSDL drag and drop, are invisible. I 
know they ain't cool, but they're important for growing this entire 
industry we're in, and they probably *don't* have a voice on this 
mailing list since they're not yet very aware of weblogs at all." [0]

Robert Sayre

[0] http://www.imc.org/atom-syntax/mail-archive/msg03106.html

---

From: Mark Pilgrim <[email-masked]>
Date: Wed, 21 Jul 2004 13:03:38 -0400

> proxy in the short run and be able to run it on their new phones

+1 on going with the protocol we really want.  I'm not convinced that
any of the vendors of "differently abled" clients are paying attention
to us in the short term anyway.

-- 
Cheers,
-Mark

---

From: Joe Gregorio <[email-masked]>
Date: Wed, 21 Jul 2004 13:22:12 -0400

> mailing list since they're not yet very aware of weblogs at all." [0]

We are an IETF Working Group. To participate, to have a voice,
is simply a matter of joining a mailing list.

-1 to trying to guessing the desires of 
    developers unwilling to join a mailing list.

-1  to guessing the desires of developers who
    don't even know they need to implement Atom yet.

    Thanks,
    -joe

---

From: Robert Sayre <[email-masked]>
Date: Wed, 21 Jul 2004 13:34:39 -0400

>     don't even know they need to implement Atom yet.

um, Anil works for a vendor of blogging software. He is telling us what 
his customers are asking for. Should I go through the mailing list 
*again* and list all of the voices in support of SOAP?

Robert Sayre

---

From: Robert Sayre <[email-masked]>
Date: Wed, 21 Jul 2004 13:54:54 -0400

Joe Gregorio wrote:

> 
> And I believe you erroneously put me on that 
> list the last time you compiled it :)

haha, yeah. I think that was the only mistake, though.

> 
> As I have stated strongly before [1], I believe the voices
> on the list are the ones that matter. 
> 

I am strongly in favor of including an optional SOAP interface in this 
WG's deliverables. It can be a MAY rather than a SHOULD.

Robert Sayre

---

From: Tim Bray <[email-masked]>
Date: Wed, 21 Jul 2004 10:46:26 -0700

>     don't even know they need to implement Atom yet.

I'm a member of this Working Group and I plan to take the needs of 
large existing communities very seriously in the design of Atom.   I 
guess there's no rule that says you have to do this, but fortunately 
there's no rule that prevents it. -Tim

---

From: Joe Gregorio <[email-masked]>
Date: Wed, 21 Jul 2004 13:47:40 -0400

[1] http://www.imc.org/atom-syntax/mail-archive/msg04636.html

    -joe

---

From: Graham <[email-masked]>
Date: Wed, 21 Jul 2004 15:26:45 -0400

On 21 Jul 2004, at 10:12 am, Bill de hÓra wrote:

> HTTP enabled devices in 3 years. In 3 years most of those 100M devices 
> will have been thrown away. So this approach will be baking in a 
> subset of HTTP for the short/medium term for what will be a miniority 
> of phones. It's the next 900M phones running HTTP that need to be 
> thought about.

Who says the next 900M phones will be running full HTTP? Your argument 
relies on all phones being sold today being sold today being capable of 
full HTTP, which is so not true. Market share figures are surprisingly 
hard to find on the web, but walk into any phone shop and you'll see 
far more J2ME handsets than Smartphones. Look at this page from Nokia 
of their latest 20 models:

  http://www.nokia.com/nokia/0,8764,73,00.html

I count 8 smartphones, 10 J2ME-enabled, and 2 that are neither. And 
most of the smartphones are niche models, the J2ME are the high-volume 
models. So, no, relying on the old handsets being thrown away is not an 
option when they still make up the majority of the market for new 
phones. If we're serious about supporting Atom on mobile phones, then 
that means J2ME.

Graham

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Wed, 21 Jul 2004 13:47:07 -0700

At 3:26 PM -0400 7/21/04, Graham wrote:
>So, no, relying on the old handsets being thrown away is not an 
>phones.

-1. You are speaking about today and next year. Our protocol will 
last a decade, at least. If we used arguments like that, we would 
never have created protocols that ran at faster than 28.8 K baud.

>  If we're serious about supporting Atom on mobile phones, then that 
>means J2ME.

-1 for the same reason. If the future market demands Atom, J2ME 
devices (or whatever doesn't handle our protocol) will change to 
handle Atom. If the future market doesn't demand Atom, there is no 
reason for us to tailor Atom for a market that doesn't care.

BUT

1) It is far from clear in this discussion whether "the protocol that 
doesn't run on J2ME" is *technically* better than "the protocol that 
runs on J2ME"

2) Even if (1) was shown to be clear, it is far from clear that "the 
protocol that doesn't run on J2ME" could not be modified to run on 
J2ME and still retain nearly the same *technical* goodness.

We're not talking about purity here. Things that are "purely" RESTy 
or "purely" SOAPy are good starting points. However, if we can step 
away from the purity in order to embrace more current platforms at no 
significant *technical* cost, we should. Doing so is not only good 
for current stuff: it helps future platforms as well.

--Paul Hoffman, Director

---

From: Bill de hÓra <[email-masked]>
Date: Wed, 21 Jul 2004 22:21:17 +0100

Graham wrote:

> Who says the next 900M phones will be running full HTTP? 

Yes, who's to say. But would you bet against them running /HTTP/?

> I count 8 smartphones, 10 J2ME-enabled, and 2 that are neither. And most 
> of the smartphones are niche models, the J2ME are the high-volume 
> models. 

For now.

> option when they still make up the majority of the market for new 

For now.

> If we're serious about supporting Atom on mobile phones, then 
> that means J2ME.

For now.

These are the premises of the counter-argument I put out:

  1. we've only seen a fraction of the HTTP/J2ME enabled devices 
that will come onto the market,

  2. today's devices and software stacks have designed-in-obsolence, 
and,

  3. future devices will harness a lot more computing and network 
power.

[Moore and Gilder are in this corner - Ding! Ding!]

I submit 2 and 3 are no-brainers and to dispute 1 is to argue that 
device adoption is topping out (if so, some of my employer's 
customers are in for a shock).

Not supporting PUT/DELETE is a random bug inherited from HTML forms 
(where HTML forms got the bright idea from I have no idea). Bug 
compatability we can live with as long as we *understand* we're 
committing the Atom specs to the sos that everyone who has come 
before us has committed their specs to. We can be serious about 
wanting supporting Atom on Java phones without wanting to subset 
HTTP as a matter of specification. It is a trade off that needs to 
be assessed without freaking out either about a zillion java phones 
or web architectural dogma.

But I'd better shut up - another thousand mobiles just shipped ;)

cheers
Bill

---

From: Dare Obasanjo <[email-masked]>
Date: Wed, 21 Jul 2004 14:36:26 -0700 (PDT)

> *again* and list all of the voices in support of

I haven't been paying much attention but I definitely
would add my voice to those who'd point out that SOAP
support should be a part of Atom to encourage wide
spread development on many popular development
platforms. 

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #95
My dungeon will have its own qualified medical staff complete with bodyguards. That way if a prisoner becomes sick and his cellmate tells the guard it's an emergency, the guard will fetch a trauma team instead of opening up the cell for a look.

__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Thu, 22 Jul 2004 01:56:02 +0200

> spread development on many popular development

+1. I'd also like to note that it's more important for me that Atom has  
_one_ mechanism to do specific things, than what that specific solution  
is. In cases like this, I don't think «the more, the merrier» applies very  
well.

-- 
Asbjørn Ulsberg         -=|=-        [email-masked]
«He's a loathsome offensive brute, yet I can't look away»

---

From: Tim Bray <[email-masked]>
Date: Wed, 21 Jul 2004 17:51:48 -0700

> +1. I'd also like to note that it's more important for me that Atom 
> has _one_ mechanism to do specific things, than what that specific 
> solution is.

I am pretty sure that there is *overwhelming* community demand for a 
REST API.  I think it very unlikely that we would agree to do SOAP but 
not REST.  So I think probably you can have _one_ *or* you can have 
SOAP.  -Tim

---

From: Julian Reschke <[email-masked]>
Date: Thu, 22 Jul 2004 08:52:13 +0200

> not REST.  So I think probably you can have _one_ *or* you can have 

+1.

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

---

From: Janne Jalkanen <[email-masked]>
Date: Thu, 22 Jul 2004 12:06:21 +0300

> of phones. It's the next 900M phones running HTTP that need to be 

At the moment there's no guarantee that they will be running anything 
else then MIDP 2.0, which does not support PUT/DELETE.

Not even within three years.  The first MIDP 1.0 phone was released in 
2001.  The first MIDP 2.0 phone was in the shops in 2004 (I think, 
could've been very late 2003.)  I don't know how the next generation 
JSRs are moving along, and when they will be deployed.

In fact, the largest growing markets are in Russia, China and India, 
where MIDP (or Brew, for that matter) will be the most commonly deployed 
platform.  Symbian and other smartphones will continue to be more 
expensive, and thus less available on those markets.

To me, supporting MIDP makes sense.

/Janne

---

From: Janne Jalkanen <[email-masked]>
Date: Thu, 22 Jul 2004 12:12:11 +0300

> are applications that demonstrate the value.

True.  And WebDAV is far more interesting in this sense than Atom, I'm 
sorry to say.

> If we decide to go for least common denominator, we need to determine 
> if we can rely on HTTP methods like DELETE and Atom specific HTTP 
> headers.

Nobody has yet mentioned any gateways that eat custom headers (except 
for one, which was not widely deployed).  I'd really like to hear these 
cries against Atom-Action header now; please mail me privately and I'll 
collect them in PaceAtomActionHeader, or post to the list.

> do, it will be hard to change the deployed base of Atom applications.

WebDAV will take care of the push for updates.

> will be a period of time where it takes for Atom to get adopted 
> widely, marketing to get the message, product designers to make the 
> product, and for the new products to get widely deployed.

Yup.  And my worst case fear is that people will look at Atom, realize 
that it takes less time to define a new format for their own use than to 
convince the product department to change their own implementation, and 
a new de-facto standard is formed.  Especially the telecom industry has 
been traditionally really bad at this; they are not used to swift 
movements like the internet industry.

> would severely affect the adoption of Atom and prevent this feedback 

Yup.

/Janne

---

From: Janne Jalkanen <[email-masked]>
Date: Thu, 22 Jul 2004 12:32:52 +0300

>to us in the short term anyway.
*cough*

I think you should be.

Seriously, the telecom world moves in general a lot slower than the 
internet world.  Mobile blogging has thus far been mostly just a game 
for a bunch of people who happen to be technically savvy.  We are seeing 
some amounts of email/sms/im publishing, but that's really only for 
"publishing".  You can't really read blogs very efficiently on your 
mobile phone either (no widespread RSS aggregators, bandwidth issues 
[think how much it would cost to check 20x20 kB RSS feeds every hour, 
not everyone supports ETags]; bloglines.com/mobile being the prime 
example I've seen on web-based aggregation, and even that borks on 
things like UTF-8 feeds).  It's all still just beginning.

Java and MIDP are going to be still in the phones for a long time (and 
we'll have to live with those limitations).  There already is a custom 
image upload API in some camera phones, but there is obvious value in 
trying to use open and public APIs for these kinds of things.  That's 
why I'm here.

-- 
Janne Jalkanen
Senior Specialist
Insight & Foresight
Corporate Strategy
Nokia Corporation

---

From: Janne Jalkanen <[email-masked]>
Date: Thu, 22 Jul 2004 15:02:45 +0300

> reason for us to tailor Atom for a market that doesn't care.

Except that the market may change according to whether Atom works or not.

If Atom is really simple to run on MIDP devices => developers will do 
stuff on it => there will be a market for Atom
If Atom is really difficult to run on MIDP devices => developers shake 
their head and go for proprietary solutions => there is no market for Atom.

We have to make that decision here, too.

> We're not talking about purity here. Things that are "purely" RESTy or 
> "purely" SOAPy are good starting points. However, if we can step away 
> from the purity in order to embrace more current platforms at no 
> significant *technical* cost, we should. Doing so is not only good for 
> current stuff: it helps future platforms as well.

Hear, hear!  This is exactly why I like the PaceAtomActionHeader so 
much; the technical impact is very low on implementations, and it 
assumes nothing of the payload format, yet it allows many 
PutDeleteBorked platforms to function :)

/Janne

---

From: Mark Baker <[email-masked]>
Date: Thu, 22 Jul 2004 10:01:39 -0400

> not REST.  So I think probably you can have _one_ *or* you can have 

Actually, I think my previous suggestion[1] is a way to get both;
only require the use of SOAP when mandatory extensions are used since
HTTP 1.1 can't do them (at least not without some other long-forgotten
spec like PEP or RFC 2774).

 [1] http://www.imc.org/atom-syntax/mail-archive/msg07433.html

Mark.