[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: issue: SOAP requirements


Dare Obasanjo wrote:

--- Joe Gregorio <joe.gregorio@xxxxxxxxx> wrote:


Some mobile phone clients (like DoJa[1], NTT

DoCoMo i-mode Java) can't

send customized HTTP headers. And I've heard

there're some mobile

gateway servers that strip out all of them, even

if agents can set.

I'm sorry, but I really don't see that as an issue,
quoting from our charter:

"The feed format and HTTP will be used as the basis
of work on a standards-track document specifying the
editing
protocol." [1]

A system that only allows GET and POST and strips headers that it doesn't know about *is not* HTTP and
I believe falls outside our charter.

That's open to interpretation - I don't see the charter saying 'hobbled HTTP deployments are outside the scope of this charter', or saying 'Atom may use any and all available aspects of HTTP'. All it says is that HTTP will be a basis.


At ETech, Sam Ruby made a comment about spec authors
needing to take responsibility for interoperability on
the Web.

Tell that to the people who shipped J2ME. Or HTML. This cuts both ways. It's a fine line, but bug-compatible is not imo always the same as interopable.


HTTP pedantry is all fine and dandy but if an option
exists that allows services that are being used by
millions of people to be Atom-enabled I don't see any
reason why they should be shut down.

Nobody is saying that Atom shouldn't use REST with all
the HTTP verbs that half the developers out there
don't even know about. However many people on the
working group have stated at one time or the other
that SOAP is important for their scenarios. If you
don't have a technical reason for objecting to this
then I'd suggest that you be productive by helping in
fleshing out what is currently an underspecified
aspect of the spec.

Well if we're talking technically, then SOAP is probably an optimal way to tunnel all of HTTP through a profile of HTTP*. And still talking technically, we don't need a SOAPAction to make this work - we can (and should) define a SOAP header instead.

It's a straight tradeoff really. Having been through this nonsense with PUT/POST I don't know how many times, I'm not fussed too much either way as I know how to work against HTTP profiles. Stripping out the SOAPAction is another matter tho'; dropping it on the floor just won't work in practice. I need a verb form to go with the payload and the most robust place for that over carrier gateways is in the SOAP header.

Specification by concession sucks, sucks, sucks.

cheers
Bill

* I'm dead serious about this.