Subject: Re: PacePutDelete Withdrawn

From: Randy Charles Morin <[email-masked]>
Date: Thu, 15 Jul 2004 07:25:48 -0700 (PDT)

Tim wrote:
>We have not yet taken up the cluster of issues around SOAP and 
>REST, and until we do, it is inappropriate to remove options 
>from consideration.
 
Let me start w/ Argggg!
 
Then a bit of, if anybody wants to own it, they should feel free to re-activate it and take up the battle. Any volunteers?
Thanks,
 
Randy
http://www.kbcafe.com

---------------------------------
Do you Yahoo!?
Take Yahoo! Mail with you! Get it on your mobile phone.

---

From: Mark Baker <[email-masked]>
Date: Thu, 15 Jul 2004 10:41:07 -0400

FWIW, it should be noted that this Pace includes an alternate proposal
which doesn't use SOAP. so it should be possible to move forward with
a solution to the PUT & DELETE problem without getting into the quagmire
that is REST vs. Web services.

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

---

From: Robert Sayre <[email-masked]>
Date: Thu, 15 Jul 2004 11:04:31 -0400

> >REST, and until we do, it is inappropriate to remove options

I'll say it too.... Arggggg!

I understand we've only recently become an official WG, but we did beat 
this to death, once upon a time. The opinions following are all positive 
towards SOAP. In my search of the archives, I found two dissenters who 
didn't later change their opinion: Russell Beattie and Tim Bray.

Any WG starts with assumptions. At this point, it seems the group is 
overwhelmingly in favor of industry-standard firewall circumvention ;)

Robert Sayre

Joe Madia:
"If the Atom API doesn't support SOAP then it appears that you are 
literally signing up for *more* spec work that results in *less* people 
being able to access the API."
http://www.imc.org/atom-syntax/mail-archive/msg03109.html

Jonas Galvez
"I just wanted to add one more 'vote' for making SOAP a standard 
alternative for the Atom API."
http://www.imc.org/atom-syntax/mail-archive/msg03110.html

Anil Dash
"I have real people asking me for SOAP-enabled blogging tools."
http://www.imc.org/atom-syntax/mail-archive/msg03106.html

David Nielson
"SOAP should stay."
http://www.imc.org/atom-syntax/mail-archive/msg03104.html

Matt Croydon
"I was unhappy to see the proposed cutting of SOAP support in the Atom 
API in PacePutDelete"
http://www.imc.org/atom-syntax/mail-archive/msg03094.html

Jason Diamond
"I don't see any reason to invent yet another messaging technology when 
the SOAP syntax seems perfectly usable by those who are and are not 
using SOAP toolkits."
http://www.imc.org/atom-syntax/mail-archive/msg03082.html

Andrew Micone
"adopting SOAP means instant compatibility with a raft of middleware 
tools by half a dozen vendors."
http://www.imc.org/atom-syntax/mail-archive/msg03118.html

Joe Gregorio
"DifferentlyAbledClients is the best avenue for SOAP enabling which 
allows clients to use WSDL, which I agree, particularly with the 
screenshot of Flash MX importing a WSDL."
http://www.imc.org/atom-syntax/mail-archive/msg03141.html

---

From: Joe Gregorio <[email-masked]>
Date: Thu, 15 Jul 2004 11:35:04 -0400

> http://www.imc.org/atom-syntax/mail-archive/msg03141.html

Sorry, but that quote isn't quite in context, but to be 
clear I do not like SOAP and believe it should be
dropped.

   Thanks,
   -joe

---

From: Ken MacLeod <[email-masked]>
Date: 15 Jul 2004 10:41:58 -0500

Robert Sayre <[email-masked]> writes:

> I understand we've only recently become an official WG, but we did
> beat this to death, once upon a time. The opinions following are all
> positive towards SOAP. In my search of the archives, I found two
> dissenters who didn't later change their opinion: Russell Beattie
> and Tim Bray.

I've been mostly ok with SOAP because it hasn't my itch to scratch,
except to spec, and that seemed to be straightforward at the time per
DifferentlyAbledClients.

The point where it became a concern for me with regards to speccing it
was when the mobile developers noted the CPU and/or bandwidth concerns
in gzipping and/or based64 encoding binary content to upload.

That was discussed heavily before, during, and following the June
face-to-face meeting.  PaceNonEntryResources first described binary
uploading using POST/PUT, and John Panzer followed up after the
meeting with PaceSimpleResourcePosting, which also supported POST,
then PUT.  John, Janne Jalkanen, Asbjørn Ulsberg, and I have been
working to merge these two Paces and are nearly complete.

Binary-upload using SOAP wrappers either leads back to base64 or
forward to MIME attachments or enclosures.  base64 doesn't solve the
mobile requirement, so it seems Atom would have to spec attachments as
well.  That's no longer straightforward.

PacePutDelete provided an alternate solution that was simpler and
didn't require base64 encoding of binary content: use an X-Atom-Method
header.

I hope that provides some background on discussing some of the
balancing points between SOAP-in-core, PacePutDelete, and multimedia
upload.

  -- Ken

---

From: Robert Sayre <[email-masked]>
Date: Thu, 15 Jul 2004 11:39:36 -0400

>clear I do not like SOAP and believe it should be

Oops. Sorry. Glad I included the link to the full email. Is it accurate 
that you would prefer SOAP to an <action> element?

Robert Sayre

---

From: Robert Sayre <[email-masked]>
Date: Thu, 15 Jul 2004 12:06:02 -0400

>didn't require base64 encoding of binary content: use an X-Atom-Method
OK. I always forget about the alternate X-Atom-Method approach mentioned 
there. Is it alleged that shipping J2ME HTTP classes allow setting of 
request headers, but not HTTP methods other than GET and POST? Are there 
any other clients that can set headers but not methods?

Robert Sayre

---

From: Tim Bray <[email-masked]>
Date: Thu, 15 Jul 2004 09:36:26 -0700

On Jul 15, 2004, at 8:04 AM, Robert Sayre wrote:

> dissenters who didn't later change their opinion: Russell Beattie and 
> Tim Bray.

OK, in that case Paul Hoffman has a problem to solve, because you are 
asserting that we already have satisfactory rough consensus on the 
basic structure of the publishing protocol, and I'm unhappy, but then 
I'm a partisan so I have to take my co-chair's hat off and throw the 
problem to Paul.

Perhaps it would help if I explained what my real problem is.

First off, I'm not against putting in a SOAP interface.  (I'm also not 
in favor, I'm totally willing to go with the flow of the WG on that).

But, when I read back over the correspondence, it seemed there was a 
possibility that neither the REST nor SOAP modes of the protocol we're 
building would be usable by today's smart cellphones that have Java, 
Brew, or equivalent.  This seems to me violently unsatisfactory, given 
that there are tens of millions of these things out there, many 
equipped with cameras, many in the hands of geeky people who would be 
likely users of Atom, and a frightening number more are being sold 
every *day*.

However, I'm not technically competent to judge this, so I've asked 
Russell Beattie and some Java heavies inside Sun who I should go hunt 
down to drop by here and advise us.  Until we get such advice, I don't 
think we should take any of our options (e.g. those in Joe's original 
Pace) definitively off the table.

By the way, if there's someone already here who can step up and explain 
authoritatively why this isn't a problem, that would be great.

Until then [speaking once again with my co-chair's hat off] I dissent 
violently to any action by this WG which might potentially 
disenfranchise the tens of millions of users of smart phones.  I don't 
*think* this should be a controversial position.  -Tim

---

From: Sam Ruby <[email-masked]>
Date: Thu, 15 Jul 2004 12:59:50 -0400

Tim Bray wrote:
> asserting that we already have satisfactory rough consensus on the basic 
> structure of the publishing protocol, and I'm unhappy, but then I'm a 
> partisan so I have to take my co-chair's hat off and throw the problem 
> to Paul.

For the record, I also would disagree with such an assertion, but as 
Secretary I also strongly agree with the comment by Randy [1] that 
Robert's comment was originally in response to.

In short, I believe that as long as this particular proposal does not 
have anybody willing to champion it, it should be retired quietly and 
Dismissed Without Prejudice[2].  To be clear, that is quite different 
than "evaluated and rejected".  It simply means that there hasn't yet 
been a proposal brought forward and evaluated by the working group to 
change what currently is in the draft.

Is somebody willing to step forward and say PacePutDelete is 
definitively THE best solution for J2ME MIDP 1.0/2.0, Flash, or any of 
the other platforms which have frowny faces on PutDeleteSupport [3]?

If not, is somebody willing to step forward and do the hard work of 
spec'ing what they think is the right solution for these platforms?

- Sam Ruby

[1] http://www.imc.org/atom-syntax/mail-archive/msg07103.html
[2] http://www.lectlaw.com/def/d062.htm
[3] http://www.intertwingly.net/wiki/pie/PutDeleteSupport

---

From: Robert Sayre <[email-masked]>
Date: Thu, 15 Jul 2004 13:21:43 -0400

> likely users of Atom, and a frightening number more are being sold 

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.

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). In fact, I gather it's often necessary to do 
so to access some phone features like wallpaper, etc. Here is an 
already-deployed Series60 app (presumably written in C++) that uses the 
Atom Publishing Protocol:

http://www.futurice.fi/products.html

Robert Sayre

---

From: Joe Gregorio <[email-masked]>
Date: Thu, 15 Jul 2004 13:56:36 -0400

> *think* this should be a controversial position.  -Tim

+1 with a caveat.

I don't think we should disenfranchise smart phones.
The caveat is that we do due dilligence to show that
we aren't twisting ourselves in knots over a small
percentage of platforms that have buggy implementations
that could be fixed with a software upgrade.

In general we need to come to some sort of decision 
on where to draw the line on asking for full
support of HTTP. As Sam pointed out, looking at the list of 
frowny faces on [1] we see some clients that have only crude
HTTP implementations. Do we not publish a protocol unless it
can be implemented on 100% of the client platforms listed?
I don't believe that is reasonable and I'd note that 
WebDAV would still be waiting to ship today
if that was the requirement.

The one bright side I would like to point out is that there 
are no frowny faces on any of the server-side platforms.

   Thanks,
   -joe

[1] http://www.intertwingly.net/wiki/pie/PutDeleteSupport

---

From: Tim Bray <[email-masked]>
Date: Thu, 15 Jul 2004 11:23:26 -0700

On Jul 15, 2004, at 10:21 AM, Robert Sayre wrote:

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

I hope you're right, but "I've been told" isn't good enough for me; I 
want to get a real expert in the room here to figure out what the right 
thing to do is.  Blogging from a smart/picture phone seems so obvious, 
if we tried to ship something that wasn't straightforward for those 
people we would be (justly) regarded as clueless, I suspect. -Tim

---

From: Tim Bray <[email-masked]>
Date: Thu, 15 Jul 2004 11:26:14 -0700

> can be implemented on 100% of the client platforms listed?

Good point, but at the recent Java One I saw ordinary 
you-can-buy-em-today cellphones playing what looked like real 
sophisticated games, and back in 2003 Murata showed me a RelaxNG 
validator running on one, so it seems likely that we should be able to 
make Atom accessible to them.   -Tim

---

From: Tim Bray <[email-masked]>
Date: Thu, 15 Jul 2004 11:23:56 -0700

> change what currently is in the draft.

On that basis, I'm OK with that. -Tim

---

From: Don Park <[email-masked]>
Date: Thu, 15 Jul 2004 15:37:43 -0700

While I am happy to hear that Joe offered to withdraw PacePutDelete, I 
agree with Tim that we need to more closely examine the options, 
particularly in the areas of mobile clients and clients with restricted 
capabilities such as J2ME and Flash.  The question is, do we have 
sufficient expertise in these areas?  Currently, people involved in this 
process are, for the most part, people with high interest in the 
blogging technology and not necessarily people with experience in 
developing applications for platforms like J2ME and Flash.

---

From: Russell Beattie <[email-masked]>
Date: Thu, 15 Jul 2004 16:13:00 -0700

Tim understated the case for cellphones. There are currently 19 mobile 
phones being sold worldwide *per second* and the majority of those are 
Java enabled. However, none of these handsets will support PUT or DELETE 
(not even MIDP 2.0 or CDLC 1.1), and the majority of these handsets have 
resource limitations and no access to the underlying hardware (most 
aren't "smart phones").

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 can enumerate the problems (and did, but deleted them to make the 
email short), but I think this issue shouldn't be tabled without looking 
at it in detail.

-Russ

---

From: Robert Sayre <[email-masked]>
Date: Thu, 15 Jul 2004 20:35:15 -0400

> power, storage and network speeds are all limited.

I don't understand why you think a full SOAP stack would be necessary. It's
been pointed out before that the difference between a SOAP doc and an Atom
doc with <action> element would come down to string constants.

Robert Sayre

---

From: Tim Bray <[email-masked]>
Date: Thu, 15 Jul 2004 19:29:55 -0700

> doc with <action> element would come down to string constants.

That sounds promising.  Is it OK to do brutally minimal profiles of 
SOAP?  Or do we run the risk of getting onto a slippery slope where 
people start assuming they can pack in arbitrary WS-* headers and other 
kinds of things that would be tractable for a general-purpose 
implementation and impossible for a handheld?

It might be really nice for someone to do a Pace to replace the current 
section 6 of draft-atompub-protocol-00 to lay out very explicitly what 
an AtomPub client has to do to use the SOAP interface.  It would be 
nice if a cellphone engineer didn't have to go and try to understand 
the entirety of the SOAP spec before starting to code. -Tim

---

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

> resource limitations and no access to the underlying hardware (most

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?

> email short), but I think this issue shouldn't be tabled without looking

I think enumerating all the problems that you know about 
would be most helpful.

    Thanks,
    -joe

---

From: Simon Fell <[email-masked]>
Date: Thu, 15 Jul 2004 22:54:53 -0700

>the entirety of the SOAP spec before starting to code. -Tim

Hmmm, for other related specs, I've noticed that you've steared clear
of restating them in the atom spec, and just referencing them. Why
make the exception here ?. Now if you were talking primer material,
then i'm all for it.

For those you think SOAP purely defines a document structure, go read
the spec, there's a processing model as well you need to follow (not a
particularly onerous one, I seem to recall seeing Sam implement the
minimal processing rules in about 4 lines of python)

Cheers
Simon
www.pocketsoap.com

---

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

> Pace) definitively off the table.

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.

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

My guess is that most complicated blog clients will be OS native anyway, 
so they are not hampered by J2ME limitations.  However, there are plenty 
of phones (such as the Nokia Series 40 phones) which do not provide user 
access to the native OS, and Java is the only way you can install 
software on those.  (These are not in general, BTW, referred to as 
"smart phones" :).

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

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.

/Janne

---

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

> already-deployed Series60 app (presumably written in C++) that uses 
> the Atom Publishing Protocol:
>

True, it's C++ and native Symbian.

(Teaches me to read all the emails before starting to reply to them :)

/Janne

---

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

> minimal processing rules in about 4 lines of python)

First, as background, to the best of my knowledge, neither Blogger's nor 
TypePad's implementation of the SOAP form of that Atom API makes use of 
anything more than an XML parser.  Both of these implementations were 
written by competent programmers with access to excellent SOAP stacks. 
It was my recommendation that such stacks (including Axis, one that I 
heavily contributed to) were overkill for this application.

I bring this up as I believe that running code is a much more effective 
argument than any amount of prose.

Simon mentions a processing model.  Much of that deals with agents and 
intermediaries.  If you are the final destination of a SOAP message, 
here is what you have to worry about:

  = = = Begin SOAP for the Squeamish = = =

1) You must be able to produce a fault.  Here[1] is a template. 
faultcode is a qname.  faultstring is a string.  detail is an any xml 
element you like in any namespace you like.  Beyond this, the values of 
these three are completely up to you.  In fact, if your application ONLY 
produces faults, you are SOAP compliant.

2) If you ever intend to do something OTHER than fault, there is still a 
case where you MUST produce a fault.  A soap:Envelope may have a single 
soap:Header.  If any of the immediate children of soap:Header have a 
soap:mustUnderstand="1" attribute, and you don't understand the header, 
then you MUST fault.

  = = = End SOAP for the Squeamish = = =

These rules can be implemented with an XML parser, one page of code, and 
one or perhaps two templates.

Applications like Atom are free to fully specify and constrain the 
schema of messages that they will accept in the Body.  Implementations 
are encouraged to ignore headers that they don't understand, unless of 
course such headers are marked mustUnderstand.

Three elements (Envelope, Body, Header) and one attribute 
(mustUnderstand) are added to your vocabulary for normal requests. 
soap:Fault, faultcode, faultstring, detail, and action (not mentioned 
above, but can be safely ignored) complete the set.

At the moment, I would recommend SOAP 1.1 as opposed to SOAP 1.2, for 
reasons similar to the request that we support XML 1.0 instead of XML 1.1.

- Sam Ruby

[1] http://www.intertwingly.net/code/mombo/template/soapfault.tmpl

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 16 Jul 2004 08:56:40 -0700

+1 and well put.

On Jul 16, 2004, at 4:23 AM, Janne Jalkanen wrote:

>> platform (e.g. Series60). In fact, I gather it's often necessary to 
>> do so to access some phone features like wallpaper, etc. Here is an 

--
Mark Nottingham     http://www.mnot.net/

---

From: Russell Beattie <[email-masked]>
Date: Sat, 17 Jul 2004 09:50:48 -0700

Peter Mortier wrote:

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

+1

I'm so happy that Peter is now here posting as he seems to be able to 
better communicate what I've been trying to say for months (year?) now.  
Thanks!

Another thing that's important to note for J2ME applications is that 
there's no concept of libraries. There's just no room for general 
purpose jars, etc. Everything has to be custom written to make things as 
small and efficient as possible. So it's not enough to find some 
workaround or assume that one SOAP expert will solve a problem and then 
it'll be put in a library and used by all. It doesn't work that way. The 
API needs to be straight forward enough to be implemented by hand.

So far the responses to this issue have been

1) Implement the HTTP protocol by hand (Why not? It's simple! Or are you 
a bad programmer?)
2) Parse SOAP by hand  (Why not? It's all in the spec! Or are you a bad 
programmer?)

and no response to the SHA1 encryption issues. Does anyone know of a 
place I can find this besides the Bouncy Castle 500k jar? (This is about 
438k bigger than a phone like the Sony Ericsson T610 can even handle).

Sam Ruby wrote:

> I bring this up as I believe that running code is a much more 
> effective argument than any amount of prose.

Okay. Here's 25 lines of J2ME-compatible Java code that post to Blogger 
using XML-RPC. No libraries needed. Someone please show me the 
equivalent Atom code. Just posting, nothing else.

    String url = "http://blogger.com/api";
    String blogId = "12345";
    String username = "username";
    String password = "password";
    String content = "&lt;title&gt;New Title!&lt;/title&gt; &lt;p&gt; 
This is a test &lt;/p&gt;";
   
    HttpConnection conn = (HttpConnection)Connector.open(url);
    conn.setRequestMethod(HttpConnection.POST);

    OutputStream os = conn.openOutputStream();;
   
    StringBuffer xml = new StringBuffer("<?xml version=\"1.0\"?>");
    xml.append("<methodCall>");
    xml.append("<methodName>blogger.newPost</methodName>");
    xml.append(" <params>");
    xml.append(" 
<param><value><string>C6CE3FFB3174106584CBB250C0B0519BF4E294</string></value></param>");
    xml.append(" <param><value><string>" + blogId + 
"</string></value></param>");
    xml.append(" <param><value><string>" + username + 
"</string></value></param>");
    xml.append(" <param><value><string>" + password + 
"</string></value></param>");
    xml.append(" <param><value><string>" + content + 
"</string></value></param>");
    xml.append(" <param><value><boolean>1</boolean></value></param>");
    xml.append(" </params>");
    xml.append("</methodCall>");

    os.write(xml.toString().getBytes());
    os.flush();

-Russ

---

From: Sam Ruby <[email-masked]>
Date: Sat, 17 Jul 2004 13:12:49 -0400

> 2) Parse SOAP by hand  (Why not? It's all in the spec! Or are you a bad 

Can we come back to this part later?  I don't mean to dismiss it, but 
lets take this one step at a time...

> 438k bigger than a phone like the Sony Ericsson T610 can even handle).

Here[1] is an implementation of sha1 in a language very close to Java. 
Can you do me a favor and evaluate what the implications are to putting 
such logic on a Sony Ericsson T610 would be?

- Sam Ruby

[1] http://www.ldodds.com/foaf/js/sha1.js

---

From: Jonas Galvez <[email-masked]>
Date: Thu, 22 Jul 2004 10:27:58 -0300

Robert Sayre wrote:
> OK. I always forget about the alternate X-Atom-Method approach
> mentioned there. Is it alleged that shipping J2ME HTTP classes allow
> setting of request headers, but not HTTP methods other than GET and
> POST? Are there any other clients that can set headers but not
> methods?

I haven't finished reading the whole thread yet, but I'd like point out
that I'm strongly in favor of the custom HTTP Header alternative, since
the Flash Player now includes a 'addRequestHeader()' method to the
LoadVars and XML classes. I think it'd be the cleanest approach.

\\ jonas galvez
// jonasgalvez.com

---

From: Jonas Galvez <[email-masked]>
Date: Thu, 22 Jul 2004 11:14:58 -0300

Jonas Galvez wrote:
> I haven't finished reading the whole thread yet, but I'd like point
> out that I'm strongly in favor of the custom HTTP Header alternative,
> since the Flash Player now includes a 'addRequestHeader()' method to
> the LoadVars and XML classes. I think it'd be the cleanest approach.

If any of you have Flash MX 2004 (or Flash MX with the latest Flash
Player in the authoring environment), try this:

     x = new XML("<test><request method=\"PUT\" /></test>");
     x.onData = function(response) {
         trace(response);
     };
     x.addRequestHeader("X-Atom-Action", "PUT");
     x.sendAndLoad("http://jonasgalvez.com/lab/http-header-test.py", x);

http-header-test.py contains:

     #!/usr/bin/python

     import os

     print "Content-type: application/xml\n"

     if os.environ["HTTP_X_ATOM_ACTION"] == "PUT":
	print '<test><response method="PUT" /></test>'

This is really exciting. I could implement a Atom client in Flash using
this technique right away, and would avoid the pain of SOAP (parsing
complex XML is also a concern in Flash Player - I've worked with - and
supported SOAP in the past - and I could clearly see the performance
issues on the thin client that is the Flash Player).

XML.addRequestHeader() is avaible on Flash Player 6 r65 and above.

\\ jonas galvez
// jonasgalvez.com

---

From: Robert Sayre <[email-masked]>
Date: Thu, 22 Jul 2004 10:36:04 -0400

> Player in the authoring environment), try this:

Or you could try dropping a WSDL file into Flash MX 2004's built-in "Web 
Services" component:

http://www.franklinmint.fm/blog/archives/images/atom_wsdl_in_flash.gif

> issues on the thin client that is the Flash Player).

Which player version? I could see having problems on Flash 5, when the 
XML Parser was written in interpreted code, but not with current 
versions. Besides, the SOAP envelope for a given entry wouldn't be much 
bigger than the entry itself.

Robert Sayre

---

From: Janne Jalkanen <[email-masked]>
Date: Thu, 22 Jul 2004 18:27:34 +0300

> issues on the thin client that is the Flash Player).

Yup.  I just hacked together an Atom API client for MIDP using the 
Atom-Action header.  Relatively trivial to do for a proof-of-concept.  
Of course, there are no servers that support it yet (I don't have the 
time to hack JSPWiki today), but it should give you an idea how it works.

(And again, this would work perfectly with binary objects as well, 
without having to bring in SOAP into the actual client.  The client jar 
seems big at 48 kB, but that's because it includes kxml2 in its 
entirety, which is completely unnecessary.  It also includes a 
rudimentary Atom feed parser.)

(Excuse my lame code, I didn't think at all while coding.  Pure 
instinct.  No WSSE support here either. And probably the <entry> written 
is not even valid. If Russ or some of the other Java überhackers on this 
list want to pick it up, that'd be cool by me.  I'm going to a four-week 
holiday starting tomorrow afternoon, so not a lot will be happening from 
my side regarding Atom :)

http://www.ecyrd.com/~jalkanen/Jello.zip

/Janne

---

From: Jonas Galvez <[email-masked]>
Date: Thu, 22 Jul 2004 12:35:36 -0300

Robert Sayre wrote:
> Or you could try dropping a WSDL file into Flash MX 2004's built-in 
> "Web Services" component:
> 
> Which player version? I could see having problems on Flash 5, when 
> the XML Parser was written in interpreted code, but not with current 
> versions. Besides, the SOAP envelope for a given entry wouldn't be 
> much bigger than the entry itself.

That component is not built into the Player. It is interpreted code as
well. XML parsing is now very fast in the Flash Player (especially in FP
7), but it is still a concern with big files. Might not be noticeable on
a high-performance machine, but on a.. say, 500Mhz computer (which a lot
of potential users of rich web apps still use), these problems become
very evident. That's not limited to XML parsing, the "built-in" (not
available in the player, must be embeded within your application) UI
components also show unsatisfactory performance. The point is: any
second of CPU processing I can save in a Flash application is worth for
me (and lots of other developer too, I believe).

I tried to elaborate about this before:
http://www.imc.org/atom-syntax/mail-archive/msg05030.html

But yes, SOAP in Flash wouldn't represent much of a problem. The Web
Service component is very convenient, but if we can do it a simpler and
faster manner, I wouldn't mind giving up on SOAP. However, I agree that
this a very tough decision. SOAP has a wide market acceptance, for
instance, Macromedia's own ColdFusion MX has a built-in mechanism for
generating WSDL files etc. Same with .NET. So SOAP would make Atom
server software development quite easy with a particular set of tools.
Anyway, I'd still stick to the X-Atom-Method approach. I like Atom's
simplicity. I like light-weight server software. SOAP is a bloated
protocol, IMHO. But that's just me. (And I know I am not being very
helpful by not providing solid technical arguments, but I believe others
already did their best showing these points and will continue to
rephrase them if necessary).

By the way, I would happily develop a FMX2004 Atom client component.

\\ jonas galvez
// jonasgalvez.com