Re: Indexed database API autoIncrement

[Shawn Wilsher]

On 10/23/2011 3:04 PM, Jonas Sicking wrote:

Good catch! This definitely needs to be specified in the spec.

I have a weak preference for using 1. This has a smaller risk of
triggering edge cases in the client code since it's always truthy.
I.e. if someone tries to detect the presence of an id, they won't fail
due to the id being 0.
Looks like there was a [loose] consensus around one, but it's not 
specified as far as I can tell.  Should I file a bug or will it get 
magically fixed with this e-mail?


Cheers,

Shawn

Re: Web Messaging Intents, was: Re: [DRAFT] Web Intents Task Force Charter

[Paul Kinlan]

On the subject of FileSaver, specifically window.saveAs, I have demos that
show use of "http://webintents.org/save"; intent which fits work very well
and it would be up to the UA to decide if they want to offer an interface
for access to the local fileSystem.  So it could either be a cloud or local
FS that the user chooses.



On Sun, Nov 13, 2011 at 11:18 PM, Paul Kinlan  wrote:

> Hi,
>
> CIL
>
> On Sun, Nov 13, 2011 at 10:35 PM, Charles Pritchard wrote:
>
>> **
>> On 11/10/11 3:10 PM, Greg Billock wrote:
>>
>>
>>
>> On Thu, Nov 10, 2011 at 8:15 AM, Rich Tibbett  wrote:
>>
>>> Dominique Hazael-Massieux wrote:
>>>
 Le jeudi 10 novembre 2011 à 16:27 +0100, Rich Tibbett a écrit :

> Hi
> a.) to register a URL endpoint as an intent provider the user must
> visit
> a web page (presumably hosted by the target device itself) and capture
> the intent registration from that page before that intent provider can
> be used within the UA.
>

 My understanding is that this is not a MUST at all, but the way
 Web-based services can be added by a user.

>>>
>>  Yes. The API as currently proposed has a way for web apps to register
>> services, but it is not intended to limit the ability of the user agent to
>> register services by other methods. If you look at our Chromium commits,
>> we're experimenting with ways to register services through installation of
>> web apps, for instance. Registering handlers through local network
>> discovery or interaction with the host OS also seems like a promising
>> direction.
>>
>>
>> Has there been further movement toward the existing register*Handler APIs:
>>
>> http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#custom-handlers
>>
>> I've practiced with those methods and from a usability perspective, I'm
>> starting to think those html5 methods are not going to be worth using.
>> Whatever the end-case, Web Intents seems to be where the UI is going to
>> evolve.
>>
>> I understand that from the Chromium-OS side, Web Intents is likely to
>> take over the fileHandlers permission.
>> That tells me that registerContentHandler is not going to happen.
>>
>
> The intent model can support "view" with the associated MIME-type which is
> what regsiterContentHandler does.  The point we need to discuss is
> registerContentHandler will implicitly start when a file is loaded with
> that mime-type, so should a UA initiate "startActivity" implicitly with a
> "view", the detected mime type and the file data?
>
>
>>
>> Chromium-OS is headed from a vendor-specific extension into web intents:
>> http://code.google.com/chrome/extensions/fileBrowserHandler.html
>>
>> I'm OK with that. I want to make sure we're all aware of the divergence.
>>
>
> I am currently tracking this.
>
>
>>
>>
>>
>>   I think the Web-page-in-a-separate tab is also an optional aspect of
 Web
 intents; the browser could serve as a broker between the local-network
 service and the Web page.

>>>
>>>  This is unclear but I hope we end up with something that provides
>>> non-tabbed (direct) interaction also. In some cases it may be superfluous
>>> to have a separate window open that denotes the service endpoint.
>>
>>
>>
>>  The proposal we're working from uses "disposition=inline" to denote
>> this -- that is, services can be placed within the visual context of the
>> calling page. Our prototype uses an expansion of the service picker dialog
>> to host that service page.
>>
>>
>>
>> It seems like the anchor download attribute fills another need. Should
>> these proposals be wrapped up into an omnibus package?
>> In my opinion, they're an extension to the very-old "target" attribute.
>>
>> In the new Web Apps world, we're targeting FileSaver and iframe sandbox.
>>
>>
>>> Thanks for the quick reply and good to ensure this stuff gets captured
>>> in the TF charter.
>>>
>>> As Chaals said, let's get going on this. The concept of Web Intents is
>>> great and we're not married to any particular proposal at this point. We
>>> can see if it works for our UCs when the task force kicks off.
>>>
>>>
>>
>>  Clarke Stevens asked about a discovery mechanism whereby a client page
>> discovers a set of local network devices which is then updated by an event
>> driven mechanism. As currently sketched out, there's room in our web
>> intents proposal for the return of a MessagePort for persistent
>> communication. The proposal doesn't focus on that problem, though. It is
>> aimed more at an RPC-style request/response interaction paradigm. Web
>> Intents, the way we're currently thinking about it, has a lot to do with
>> user consent to the connection between the applications. When there's a
>> persistent connection, that consent model starts to break down. That said,
>> there are definitely use cases for which establishing a persistent
>> connection is appropriate. I'm eager to discuss how to best handle those
>> cases as the TF starts up. I think that'll be a key fo

Re: Web Messaging Intents, was: Re: [DRAFT] Web Intents Task Force Charter

[Paul Kinlan]

Hi,

CIL

On Sun, Nov 13, 2011 at 10:35 PM, Charles Pritchard  wrote:

> **
> On 11/10/11 3:10 PM, Greg Billock wrote:
>
>
>
> On Thu, Nov 10, 2011 at 8:15 AM, Rich Tibbett  wrote:
>
>> Dominique Hazael-Massieux wrote:
>>
>>> Le jeudi 10 novembre 2011 à 16:27 +0100, Rich Tibbett a écrit :
>>>
 Hi
 a.) to register a URL endpoint as an intent provider the user must visit
 a web page (presumably hosted by the target device itself) and capture
 the intent registration from that page before that intent provider can
 be used within the UA.

>>>
>>> My understanding is that this is not a MUST at all, but the way
>>> Web-based services can be added by a user.
>>>
>>
>  Yes. The API as currently proposed has a way for web apps to register
> services, but it is not intended to limit the ability of the user agent to
> register services by other methods. If you look at our Chromium commits,
> we're experimenting with ways to register services through installation of
> web apps, for instance. Registering handlers through local network
> discovery or interaction with the host OS also seems like a promising
> direction.
>
>
> Has there been further movement toward the existing register*Handler APIs:
>
> http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#custom-handlers
>
> I've practiced with those methods and from a usability perspective, I'm
> starting to think those html5 methods are not going to be worth using.
> Whatever the end-case, Web Intents seems to be where the UI is going to
> evolve.
>
> I understand that from the Chromium-OS side, Web Intents is likely to take
> over the fileHandlers permission.
> That tells me that registerContentHandler is not going to happen.
>

The intent model can support "view" with the associated MIME-type which is
what regsiterContentHandler does.  The point we need to discuss is
registerContentHandler will implicitly start when a file is loaded with
that mime-type, so should a UA initiate "startActivity" implicitly with a
"view", the detected mime type and the file data?


>
> Chromium-OS is headed from a vendor-specific extension into web intents:
> http://code.google.com/chrome/extensions/fileBrowserHandler.html
>
> I'm OK with that. I want to make sure we're all aware of the divergence.
>

I am currently tracking this.


>
>
>
>   I think the Web-page-in-a-separate tab is also an optional aspect of Web
>>> intents; the browser could serve as a broker between the local-network
>>> service and the Web page.
>>>
>>
>>  This is unclear but I hope we end up with something that provides
>> non-tabbed (direct) interaction also. In some cases it may be superfluous
>> to have a separate window open that denotes the service endpoint.
>
>
>
>  The proposal we're working from uses "disposition=inline" to denote this
> -- that is, services can be placed within the visual context of the calling
> page. Our prototype uses an expansion of the service picker dialog to host
> that service page.
>
>
>
> It seems like the anchor download attribute fills another need. Should
> these proposals be wrapped up into an omnibus package?
> In my opinion, they're an extension to the very-old "target" attribute.
>
> In the new Web Apps world, we're targeting FileSaver and iframe sandbox.
>
>
>> Thanks for the quick reply and good to ensure this stuff gets captured in
>> the TF charter.
>>
>> As Chaals said, let's get going on this. The concept of Web Intents is
>> great and we're not married to any particular proposal at this point. We
>> can see if it works for our UCs when the task force kicks off.
>>
>>
>
>  Clarke Stevens asked about a discovery mechanism whereby a client page
> discovers a set of local network devices which is then updated by an event
> driven mechanism. As currently sketched out, there's room in our web
> intents proposal for the return of a MessagePort for persistent
> communication. The proposal doesn't focus on that problem, though. It is
> aimed more at an RPC-style request/response interaction paradigm. Web
> Intents, the way we're currently thinking about it, has a lot to do with
> user consent to the connection between the applications. When there's a
> persistent connection, that consent model starts to break down. That said,
> there are definitely use cases for which establishing a persistent
> connection is appropriate. I'm eager to discuss how to best handle those
> cases as the TF starts up. I think that'll be a key focus of refinement.
>
>
> Hixie made a good point when he asked us to review Web Messaging. Intents
> as it's implemented by Google -- and it's already happening -- Google
> started this push awhile ago and I get the impression that Paul Kinlan has
> high level support -- intents as it's implemented is built upon Web
> Messaging and postMessage dynamics.
>
> postMessage has MessagePort and Transferable arrays (thank goodness). I
> believe those semantics already solve issues of RPC, bi-di and zero-copy.
> They've ha

Web Messaging Intents, was: Re: [DRAFT] Web Intents Task Force Charter

[Charles Pritchard]

On 11/10/11 3:10 PM, Greg Billock wrote:



On Thu, Nov 10, 2011 at 8:15 AM, Rich Tibbett > wrote:


Dominique Hazael-Massieux wrote:

Le jeudi 10 novembre 2011 à 16:27 +0100, Rich Tibbett a écrit :

Hi
a.) to register a URL endpoint as an intent provider the
user must visit
a web page (presumably hosted by the target device itself)
and capture
the intent registration from that page before that intent
provider can
be used within the UA.


My understanding is that this is not a MUST at all, but the way
Web-based services can be added by a user.


Yes. The API as currently proposed has a way for web apps to register 
services, but it is not intended to limit the ability of the user 
agent to register services by other methods. If you look at our 
Chromium commits, we're experimenting with ways to register services 
through installation of web apps, for instance. Registering handlers 
through local network discovery or interaction with the host OS also 
seems like a promising direction.


Has there been further movement toward the existing register*Handler APIs:
http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#custom-handlers

I've practiced with those methods and from a usability perspective, I'm 
starting to think those html5 methods are not going to be worth using.
Whatever the end-case, Web Intents seems to be where the UI is going to 
evolve.


I understand that from the Chromium-OS side, Web Intents is likely to 
take over the fileHandlers permission.

That tells me that registerContentHandler is not going to happen.

Chromium-OS is headed from a vendor-specific extension into web intents:
http://code.google.com/chrome/extensions/fileBrowserHandler.html

I'm OK with that. I want to make sure we're all aware of the divergence.




I think the Web-page-in-a-separate tab is also an optional
aspect of Web
intents; the browser could serve as a broker between the
local-network
service and the Web page.


This is unclear but I hope we end up with something that provides
non-tabbed (direct) interaction also. In some cases it may be
superfluous to have a separate window open that denotes the
service endpoint.



The proposal we're working from uses "disposition=inline" to denote 
this -- that is, services can be placed within the visual context of 
the calling page. Our prototype uses an expansion of the service 
picker dialog to host that service page.



It seems like the anchor download attribute fills another need. Should 
these proposals be wrapped up into an omnibus package?

In my opinion, they're an extension to the very-old "target" attribute.

In the new Web Apps world, we're targeting FileSaver and iframe sandbox.



Thanks for the quick reply and good to ensure this stuff gets
captured in the TF charter.

As Chaals said, let's get going on this. The concept of Web
Intents is great and we're not married to any particular proposal
at this point. We can see if it works for our UCs when the task
force kicks off.



Clarke Stevens asked about a discovery mechanism whereby a client page 
discovers a set of local network devices which is then updated by an 
event driven mechanism. As currently sketched out, there's room in our 
web intents proposal for the return of a MessagePort for persistent 
communication. The proposal doesn't focus on that problem, though. It 
is aimed more at an RPC-style request/response interaction paradigm. 
Web Intents, the way we're currently thinking about it, has a lot to 
do with user consent to the connection between the applications. When 
there's a persistent connection, that consent model starts to break 
down. That said, there are definitely use cases for which establishing 
a persistent connection is appropriate. I'm eager to discuss how to 
best handle those cases as the TF starts up. I think that'll be a key 
focus of refinement.


Hixie made a good point when he asked us to review Web Messaging. 
Intents as it's implemented by Google -- and it's already happening -- 
Google started this push awhile ago and I get the impression that Paul 
Kinlan has high level support -- intents as it's implemented is built 
upon Web Messaging and postMessage dynamics.


postMessage has MessagePort and Transferable arrays (thank goodness). I 
believe those semantics already solve issues of RPC, bi-di and 
zero-copy. They've had years of work put into them to get to this place 
of consensus.


timeless brought up some excellent corner cases that I hope are 
discussed soon in the upcoming TF mailing list. That stated, I think 
building Intents atop postMessage is the right move. Web Messaging has 
already solved many of the difficult problems.


As far as I can tell, Web Intents adds another high level semantic: the 
"Intent" semantic. I've

Re: Discovery and Web Intents (was Re: [DRAFT] Web Intents Task Force Charter)

[Dave Raggett]

On 12/11/11 11:42, Giuseppe Pascale wrote:

* The UI web page should be able to handle devices appearing and
disappearing at random times and be notified of such via events. Is this
possible?


I'm wondering if tḧis is actually needed. If you handle the "picker"
natively, I think also this aspect will have to be handled by the browser
and not exposed to the application.


Such events are needed for context aware applications, but this is 
probably outside the scope of an initial web intents/local discovery API 
where as you suggest, the web run-time could handle this as part of the 
picker API and  the associated background service  monitoring the 
multicast datagrams for mDNS and SSDP, and likewise for other 
interconnect technologies such as USB and Bluetooth.



Also this is probably not part of the web intent discussion. Web intents
provide the general infrastructure. How do we map specific services on
intent should be handled by another spec and probably discussed in DAP 
(or

not?). We have 2 options here: have different intents for different
protocols or one intent that try to cover all similar services. The first
one is easier to implement, the second is much more handy for 
applications

developers. I'm starting to think that we should try to go for the second
option. If we go for that we will have to address the problem of
differences in capability between different (similar) services/protocols.


Agreed. We could go for a high level abstraction, but at the same time 
expose the protocol specific details for applications/libraries that 
need it. One way to do this as sub-objects for specific protocols, e.g. 
an UPnP object that provides access to the service descriptions UPnP 
defines in XML.


--
 Dave Raggett  http://www.w3.org/People/Raggett

Re: [DRAFT] Web Intents Task Force Charter

[Greg Billock]

On Thu, Nov 10, 2011 at 8:15 AM, Rich Tibbett  wrote:

> Dominique Hazael-Massieux wrote:
>
>> Le jeudi 10 novembre 2011 à 16:27 +0100, Rich Tibbett a écrit :
>>
>>> Hi
>>> a.) to register a URL endpoint as an intent provider the user must visit
>>> a web page (presumably hosted by the target device itself) and capture
>>> the intent registration from that page before that intent provider can
>>> be used within the UA.
>>>
>>
>> My understanding is that this is not a MUST at all, but the way
>> Web-based services can be added by a user.
>>
>
Yes. The API as currently proposed has a way for web apps to register
services, but it is not intended to limit the ability of the user agent to
register services by other methods. If you look at our Chromium commits,
we're experimenting with ways to register services through installation of
web apps, for instance. Registering handlers through local network
discovery or interaction with the host OS also seems like a promising
direction.



> I think the Web-page-in-a-separate tab is also an optional aspect of Web
>> intents; the browser could serve as a broker between the local-network
>> service and the Web page.
>>
>
> This is unclear but I hope we end up with something that provides
> non-tabbed (direct) interaction also. In some cases it may be superfluous
> to have a separate window open that denotes the service endpoint.



The proposal we're working from uses "disposition=inline" to denote this --
that is, services can be placed within the visual context of the calling
page. Our prototype uses an expansion of the service picker dialog to host
that service page.


> Thanks for the quick reply and good to ensure this stuff gets captured in
> the TF charter.
>
> As Chaals said, let's get going on this. The concept of Web Intents is
> great and we're not married to any particular proposal at this point. We
> can see if it works for our UCs when the task force kicks off.
>
>

Clarke Stevens asked about a discovery mechanism whereby a client page
discovers a set of local network devices which is then updated by an event
driven mechanism. As currently sketched out, there's room in our web
intents proposal for the return of a MessagePort for persistent
communication. The proposal doesn't focus on that problem, though. It is
aimed more at an RPC-style request/response interaction paradigm. Web
Intents, the way we're currently thinking about it, has a lot to do with
user consent to the connection between the applications. When there's a
persistent connection, that consent model starts to break down. That said,
there are definitely use cases for which establishing a persistent
connection is appropriate. I'm eager to discuss how to best handle those
cases as the TF starts up. I think that'll be a key focus of refinement.

Re: Identifying "Test Spec Editors"; deadline Nov 11

[Charles McCathieNevile]

On Sat, 12 Nov 2011 14:09:15 +0100, Arthur Barstow   
wrote:



On 11/11/11 7:53 PM, ext Adrian Bateman wrote:

On Friday, November 04, 2011 4:59 PM, Arthur Barstow wrote:

One of the topics discussed this week was to designate a "Test Spec
Editor(s)" for each of our specs.

We're supportive of this idea.


(BTW, the title of "Test Spec Editor" is a bit of a straw-man, so
proposals for other titles are also welcome.)
I wonder if Test Suite Facilitator (or similar) is a better title. We  
use "Facilitator"
in HTML WG and I think it may be more of a coordination role than a  
person that does
all the editing work of the test suite (that's how it seems to work in  
HTML at the

moment).


If anyone objects to "Test Facilitator", please speak up; otherwise, at  
the end of next week I will add that role to PubStatus' Testing column  
and issue some type of Call for Test Facilitators for our various test  
suites:


I positively support it, basically for the reasons Adrian outlined.

cheers

--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan litt norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com