Network API editor's draft

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Network API editor's draft

Charles McCathieNevile-2

Hi folks.

Thanks to Gorm and the WHATWG, we have http://dev.w3.org/cvsweb/~checkout~/2006/webapi/network-api/network-api.html

Comments and brickbats welcome

cheers

Chaals

--
  Charles McCathieNevile, Opera Software: Standards Group
  hablo español  -  je parle français  -  jeg lærer norsk
[hidden email]          Try Opera 9.1     http://opera.com

Reply | Threaded
Open this post in threaded view
|

Re: Network API editor's draft

Ian Hickson

On Wed, 7 Mar 2007, Charles McCathieNevile wrote:
>
> Thanks to Gorm and the WHATWG, we have
> http://dev.w3.org/cvsweb/~checkout~/2006/webapi/network-api/network-api.html

Note that the WHATWG version of this draft is in heavy flux; there are
hundreds of outstanding comments on it. Is the intent that this
specification replace the WHATWG version? (I am reluctant to just remove
the WHATWG part of the text because development on the last specification
for which I did that -- the Window spec -- has now ground to a halt and
left me with significant extra work, as I now have to move the definitions
back to HTML5 to deal with the more complicated cases which the Windows
spec says are out of scope.)

Could you give an exact list of the changes between the WHATWG draft and
this one? (Ideally to the level of individual word and markup changes?)

Cheers,
--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Reply | Threaded
Open this post in threaded view
|

Re: Network API editor's draft

Charles McCathieNevile-2

On Thu, 08 Mar 2007 06:27:50 +1100, Ian Hickson <[hidden email]> wrote:

> Note that the WHATWG version of this draft is in heavy flux; there are
> hundreds of outstanding comments on it. Is the intent that this
> specification replace the WHATWG version?

Hmm. It is intended to be used by a similar audience. There is no compulsion on the WHAT-WG to remove their version at any given time, and maybe keeping it for now would motivate people to actually work on the spec.

> (I am reluctant to just remove
> the WHATWG part of the text because development on the last specification
> for which I did that -- the Window spec -- has now ground to a halt and
> left me with significant extra work, as I now have to move the definitions
> back to HTML5 to deal with the more complicated cases which the Windows
> spec says are out of scope.)

Yes. I am sorry that the editors of that spec have slowed down. As you are aware, most spec editors are squeezing it in with other responsibilities, which sometimes has the unfortunate result that things don't move as fast as hoped.

> Could you give an exact list of the changes between the WHATWG draft and
> this one? (Ideally to the level of individual word and markup changes?)

No, I can't, sorry. Perhaps Gorm has time to give some reasonable level of detail. The summary I can provide is "it is the TCP connection stuff out of the spec".

Cheers

Chaals

--
  Charles McCathieNevile, Opera Software: Standards Group
  hablo español  -  je parle français  -  jeg lærer norsk
[hidden email]          Try Opera 9.1     http://opera.com

Reply | Threaded
Open this post in threaded view
|

Re: Network API editor's draft

Ian Hickson

On Thu, 8 Mar 2007, Charles McCathieNevile wrote:
> >
> > Note that the WHATWG version of this draft is in heavy flux; there are
> > hundreds of outstanding comments on it. Is the intent that this
> > specification replace the WHATWG version?
>
> Hmm. It is intended to be used by a similar audience. There is no
> compulsion on the WHAT-WG to remove their version at any given time, and
> maybe keeping it for now would motivate people to actually work on the
> spec.

Well, the two specs are incompatible (they define the same thing, so any
differences between the two would be a problem to someone implementing
both). So eventually, one has to go. I'd assume the intent is to
eventually drop the WHATWG one, but, well, see my comments about Window.


> > (I am reluctant to just remove the WHATWG part of the text because
> > development on the last specification for which I did that -- the
> > Window spec -- has now ground to a halt and left me with significant
> > extra work, as I now have to move the definitions back to HTML5 to
> > deal with the more complicated cases which the Windows spec says are
> > out of scope.)
>
> Yes. I am sorry that the editors of that spec have slowed down. As you
> are aware, most spec editors are squeezing it in with other
> responsibilities, which sometimes has the unfortunate result that things
> don't move as fast as hoped.

Oh I'm not complaining, and I fully understand Maciej's position and do
not at all blame him. I'm just making an observation, to explain my
reluctance to move the specs around too quickly.


> > Could you give an exact list of the changes between the WHATWG draft
> > and this one? (Ideally to the level of individual word and markup
> > changes?)
>
> No, I can't, sorry. Perhaps Gorm has time to give some reasonable level
> of detail. The summary I can provide is "it is the TCP connection stuff
> out of the spec".

I think we will need to have very, very close cooperation (to the level of
word-smithing and markup change diffs) if we want to work together on
this. If you could get such a list of changes that would be really
helpful. It would be quite a problem if we tried to keep them in sync but
in a year four that the specs have differences in the fundamental
assumptions.

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Reply | Threaded
Open this post in threaded view
|

RE: Network API editor's draft

mikewse
In reply to this post by Charles McCathieNevile-2

Hi Charles,

I see only non-blocking communication in the draft. This is
probably intentional, but adding the possibility for "blocking
sockets" would provide more flexibility for the developer, and
make some problems easier to solve.

This could be provided in different ways, f ex through a
connection instance method recv() that would block until data
arrives on the specified connection.

When implementing any protocol containing a couple of
handshaking layers it is convenient to be able to say "now I
want to wait until at least four bytes arrives". Without the
blocking feature you tend to end up with a maze of asynchronous
handler functions or overly complex state-machines.

To avoid inventing yet another "synchronous XMLHttpRequest kills
the window" scenario, the following could be considered:
- possible to specify timeout for how long to block
- handle ui events while blocking (so browser window is "alive")
- potentially let browser's stop button abort blocking

Also, blocking is your only chance if you want to send (and
acknowledge) something at page exit, from inside the
Window.onunload handler.

Best regards
Mike Wilson

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Charles
> McCathieNevile
> Sent: den 7 mars 2007 08:27
> To: web API
> Subject: Network API editor's draft
>
>
> Hi folks.
>
> Thanks to Gorm and the WHATWG, we have
> http://dev.w3.org/cvsweb/~checkout~/2006/webapi/network-api/ne
twork-api.html

>
> Comments and brickbats welcome
>
> cheers
>
> Chaals
>
> --
>   Charles McCathieNevile, Opera Software: Standards Group
>   hablo español  -  je parle français  -  jeg lærer norsk
> [hidden email]          Try Opera 9.1     http://opera.com
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Network API editor's draft

Gorm Haug Eriksen
In reply to this post by Ian Hickson

On Wed, 07 Mar 2007 23:07:36 +0100, Ian Hickson <[hidden email]> wrote:

> On Thu, 8 Mar 2007, Charles McCathieNevile wrote:
>> >
>> > Note that the WHATWG version of this draft is in heavy flux; there are
>> > hundreds of outstanding comments on it. Is the intent that this
>> > specification replace the WHATWG version?
>>
>> Hmm. It is intended to be used by a similar audience. There is no
>> compulsion on the WHAT-WG to remove their version at any given time, and
>> maybe keeping it for now would motivate people to actually work on the
>> spec.
>
> Well, the two specs are incompatible (they define the same thing, so any
> differences between the two would be a problem to someone implementing
> both). So eventually, one has to go. I'd assume the intent is to
> eventually drop the WHATWG one, but, well, see my comments about Window.

Hi Ian,

I share your concern. First of all, the current specification is only the  
TCPConnection part from the WHATWG specification with some modifications.  
This was the part of the specification that was closest to mature  
(although there are multiple issues with it that need to be addressed).

Note that the current specification doesn't follow the charter for the  
group and one of these documents would need to be rewritten. According to  
the charter: "Network communication methods covered by this deliverable  
are network sockets and possibly protocols other than HTTP. This allows a  
Web application to perform more networking operations (eg. IRC, other  
instant messaging protocols, Java Message Service and Session Initiation  
Protocol). Also, it may be necessary to produce documentation for, or a  
specification of, connection policy and security."

I'm also a bit concerned that I don't know of browser which has  
implemented the TCPConnection object from the WHATWG specification.

Personally I would rather see the W3C network API become a low level  
socket API with an optional security model/policy. This would also be more  
aligned toward the charter for this group.

With regards to the changes from the WHATWG specification:

- Connection, PeerToPeerConnection and LocalBroadCastConnection interfaces  
are removed including the sections describing these connections
- the network attribute on the TCPConnection interface is removed
- WHATWG doesn't mention any security exception so I have used the  
SECURITY_ERR from WHATWG (which has an open issue on not being defined in  
that spec)
- the source attribute on the ConnectionReadEvent is removed
- WindowHTML is renamed to Window
- a pointer from the TCPConnection to the Window object is added (like on  
XMLHttpRequest)
- "The common protocol for TCP-based connections" is renamed to  
"Communication on the network"
- the part about initializing a connecting in "TCP connections" is moved  
to a new section called "Initializing the TCPConnection object"
- the part about constructing the TCPConnection object in "TCP  
connections" is moved to a new section called "The TCPConnection  
constructor"

--
Cheers,

- Gorm