Subject: Re: PacePutDelete Withdrawn

From: [email-masked]
Date: 18 Jul 2004 15:39:37 -0000

--- Martin Duerst <[email-masked] wrote:

> >HTTP-over-WSP connectivity is
the standard for mobile 2G networks
> >(f.e. GSM-CSD).
> This is an
overstatement. I'm not at all an expert in this area,

You are right, it
is an overstatement.

> but I know for sure that most Japanese phones (2G
or otherwise) don't use WAP at all. 

You're right. In Japan NTT Docomo
uses iMode, a packet oriented network, which also uses a gateway.
Since I
really am not an iMode expert, I asked Google for some advice. 
It looks
like Japan's largest operator NTT Docomo uses a gateway developed by Nec [1].

An older article describes iMode's technical architecture [2]. I find the
following section on HTTP interesting:

"The microbrowser sits on top of
a protocol named Application Layer Protocol (ALP), developed by DoCoMo as
the mobile client-side version of standard HTTP. The conversion between HTTP
and ALP is transparent to the subscriber and to the sending Web server. It
reduces client burden by removing HTTP header data (which is not needed by
the Mobile Station), instituting a termination notification signal and converting
SMTP mail text to cHTML format."

Unfortunately it does not say which HTTP
methods are required and/or supported. Any iMode expert present willing to
elaborate/investigate?

> And there are lots of mobile phones with
> HTTP
and HTML support in Japan.

Yep, and in other parts of the world too. Mobile
networks and application environments are heterogenous. Most network operators
introduce a gateway between their mobile network and the Internet and these
gateways possibly have limitations for full REST support.

Eventually, mobile
applications will have full REST support. Efforts like Atom could even accelerate
REST adoption in the mobile space.

I would personally love to have the
Nokia people on this list to pressure their MIDP departement, to change their
MIDP implementation to support full REST when possible. I would love it even
more, if this would be available as a firmware upgrade for my Nokia 3650.
I would be in heaven if Nokia provided a way for me to upgrade my firmware
via the Internet and a PC connection or even directly from my mobile. Currently
I have to go to my local Nokia service center to get my phone flashed for
firmware upgrades.

I'm realistic enough to realize that I don't have any
influence on Nokia's business decisions and that this probably won't happen
anytime soon.

I'm willing to do some leg work to examine Atom's feasability
for my geographical area (Europe) and preferred client platform (MIDP). 
It's definately not a niche market for Atom and this WG should be aware of
its limitations to make informed decisions.

Regards,

Peter
 
[1] http://www.3g.co.uk/PR/May2003/5334.htm

[2] http://www.awprofessional.com/articles/article.asp?p=27009

---

From: Tim Bray <[email-masked]>
Date: Sun, 18 Jul 2004 09:09:40 -0700

It dawns on me that there is another popular application platform with 
support for GET and POST but not PUT nor DELETE.  That would be a Web 
Browser.  Thus, if the full capabilities of Atom were available using 
only GET and POST I would be able to do a full client implementation as 
a set of HTML pages with no reliance on server-side scripts, right?  
Given that the browser is becoming a locus of innovation again (see 
Apache, WHAT-WG) this seems potentially quite significant. -Tim

---

From: Joe Gregorio <[email-masked]>
Date: Sun, 18 Jul 2004 12:39:31 -0400

> Apache, WHAT-WG) this seems potentially quite significant. -Tim

How, exactly, would you POST XML via a web page?

HTTP web pages only support GET and POST of content of the form
x-www-form-urlencoded. 

XForms supports XML and PUT but not DELETE, though there
might be vendor extensions for all HTTP methods. Also,  
at this point XForms has a tiny market share.

If you are going to use JavaScript then both IE and Mozilla
based browsers have extensions that support full
HTTP including all the methods.

    -joe

-- 
Joe Gregorio        http://bitworking.org

---

From: Robert Sayre <[email-masked]>
Date: Sun, 18 Jul 2004 12:44:19 -0400

> a set of HTML pages with no reliance on server-side scripts, right?

The data would be sent as "application/x-www-form-urlencoded". In the
archives, you can find an email from Jason Diamond catching me forgetting
this. So I think this would be a separate gateway, one that most blogging
software already has.

> Apache, WHAT-WG) this seems potentially quite significant. -Tim

WHAT-WG is going to have PUT/DELETE capability for forms.

Also, you could build a ReST Atom client in javascript, using the XMLHTTP
object. This code would work in IE6 and recent versions of Mozilla. Safari
also has XMLHTTP support scheduled. It's one of those de-facto IE standards
that is actually pretty good.

Robert Sayre

---

From: Ken MacLeod <[email-masked]>
Date: 18 Jul 2004 11:58:24 -0500

Tim Bray <[email-masked]> writes:

> It dawns on me that there is another popular application platform
> with support for GET and POST but not PUT nor DELETE.  That would be
> a Web Browser.  Thus, if the full capabilities of Atom were
> available using only GET and POST I would be able to do a full
> client implementation as a set of HTML pages with no reliance on
> server-side scripts, right?  Given that the browser is becoming a
> locus of innovation again (see Apache, WHAT-WG) this seems
> potentially quite significant. -Tim

The current browsers don't support forms that use <atom:entry>
elements, either, so I think that would be a bigger problem in using a
browser as an Atom protocol client.

On the other hand, with regards to the WHAT-WG's support of Atom,
Asbjørn (quarkie) writes in chat[1]:

  <quarkie> something that might interest veryone; I've queried WHAT
  WG on the Web Forms 2.0 proposal on the case where a web browser can
  act as an Atom API client

  <quarkie> Ian Hickson made a swift reply, where he explains that Web
  Forms 2.0 is going to support PUT and DELETE as '@method's on <form>
  as well as an unlimited amount of values for '@enctype'

  <bitsko> you'd have to rewrite the Atom specs to support form input,
  no?

  <quarkie> yup. as he writes: "If the Atom spec specifies how to
  convert a Web Forms 2.0 form data set into an 'application/atom+xml'
  encoded form data set, then UAs can implement it."

'bitsko' is my IRC nick.

  -- Ken

[1] http://www.ilrt.bris.ac.uk/discovery/chatlogs/atom/2004-07-04.html#T16-21-27

---

From: Mark Pilgrim <[email-masked]>
Date: Sun, 18 Jul 2004 13:10:12 -0400

> that is actually pretty good.

http://www.isolani.co.uk/blog/atom/JavascriptAtomApiClientUsingXmlHttpRequest

-- 
Cheers,
-Mark

---

From: Henri Sivonen <[email-masked]>
Date: Sun, 18 Jul 2004 23:45:47 +0300

>   encoded form data set, then UAs can implement it."

What would be the point of burdening a Web Forms 2.0 UA with Atom? If 
you are able to spec how to build an Atom entry out of a form dataset, 
surely the conversion can be done on the server instead of introducing 
yet another submission format for UAs to support.

-- 
Henri Sivonen
[email-masked]
http://iki.fi/hsivonen/

---

From: Martin Duerst <[email-masked]>
Date: Mon, 19 Jul 2004 10:28:26 +0900

>methods are required and/or supported. Any iMode expert present willing to

I'm trying to get that information from a friend.

Regards,    Martin.

---

From: Ken MacLeod <[email-masked]>
Date: 19 Jul 2004 10:17:02 -0500

Henri Sivonen <[email-masked]> writes:

> >   convert a Web Forms 2.0 form data set into an
> >   'application/atom+xml' encoded form data set, then UAs can
> >   implement it."
> 
> What would be the point of burdening a Web Forms 2.0 UA with Atom?
> If you are able to spec how to build an Atom entry out of a form
> dataset, surely the conversion can be done on the server instead of
> introducing yet another submission format for UAs to support.

It's not burdening Web Forms 2.0 UA with Atom, it's Web Forms 2.0 UA
being XML and REST enabled.  The conversion between XML and Form is
done with a supplied stylesheet.

I suspect the end result will be something like Naked Objects[1] over
the web.

The point is that they're speccing PUT and DELETE for forms and for
use with formats like ours, and we'll get to see how it works out in
practice with "just a browser".

  -- Ken

[1] http://www.nakedobjects.org/

---

From: Henri Sivonen <[email-masked]>
Date: Mon, 19 Jul 2004 20:24:37 +0300

On Jul 19, 2004, at 18:17, Ken MacLeod wrote:

> being XML and REST enabled.

XML and REST don't imply Atom envelopes. In fact, one might argue that 
in order to publish HTML it would be more RESTian to PUT straight HTML 
without an envelope.

> The conversion between XML and Form is done with a supplied stylesheet.

I think you mean an XSLT transformation. I don't think solutions that 
require client-side XSLT will end up in Web Forms 2.0.

See:
http://www.hixie.ch/advocacy/xslt
http://groups.google.com/groups?selm=oprtucqzcxn2y593%40news.opera.com

(FWIW, I agree with Hixie on XSLT as far as the client side goes.)

-- 
Henri Sivonen
[email-masked]
http://iki.fi/hsivonen/

---

From: Robert Sayre <[email-masked]>
Date: Mon, 19 Jul 2004 14:02:38 -0400

> in order to publish HTML it would be more RESTian to PUT straight HTML 

That would work if websites weren't covered in "chrome". However, I do 
agree with you here. The WHAT-WG forms spec is geared towards 
serialization of arbitrary datasets[0] without requiring very specific 
HTTP interaction. Atom isn't general enough for Web Forms 2.0[1]. It's a 
better fit for Web Applications 1.0[2], another of their specs. I've 
stated this opinion their mailing list[3].

It seems the WHAT-WG is focusing on standardizing functionality that is 
commonly achieved with JavaScript (e.g. date controls, email fields). If 
AtomPP.js files become really common, they can standardize it in the future.

Robert Sayre

[0] http://www.whatwg.org/specs/web-forms/current-work/#x-www-form-xml
[1] http://www.whatwg.org/specs/web-forms/current-work/
[2] http://www.whatwg.org/specs/web-apps/current-work/
[3] 
http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2004-July/001195.html

---

From: Henri Sivonen <[email-masked]>
Date: Mon, 19 Jul 2004 21:45:44 +0300

On Jul 19, 2004, at 21:02, Robert Sayre wrote:

>> XML and REST don't imply Atom envelopes. In fact, one might argue 
>> that in order to publish HTML it would be more RESTian to PUT 
>> straight HTML without an envelope.
>
> That would work if websites weren't covered in "chrome".

I don't see how taking the stuff out of an Atom envelope before 
wrapping it in the chrome helps compared to taking the stuff out of an 
HTML body and wrapping it in the chrome.

-- 
Henri Sivonen
[email-masked]
http://iki.fi/hsivonen/

---

From: Robert Sayre <[email-masked]>
Date: Mon, 19 Jul 2004 15:00:49 -0400

> HTML body and wrapping it in the chrome.

We're getting OT here, but the problem with HTML is that the websites 
put their own chrome throughout the body. People have been requesting 
<header> and <navigation> extensions for precisely this reason. There's 
always contenteditable, if that fits your needs.

Robert Sayre