Re: Web Intents/Web Activities F2F get-together report
(+public-webapps; I apologize, I thought I'd included that list yesterday) Yes, I think discussions on this list would be helpful. I think the F2F time is probably better spent elsewhere in June; that's a bit of projection about how much we can learn in the meantime. We're very interested in the Web Activities launch -- that'll teach us a lot. On Fri, Mar 22, 2013 at 8:01 AM, wrote: > Greg > > Thanks for the report, and thanks to you Darin, Jonas and Mounir for > meeting. > > I assume that this means we will (1) continue with some deeper > discussions and proposals on this list and (2) that we can and should > reserve time (e.g. a day or 1 1/2 days) in the DAP F2F agenda 4-6 June for > this topic [1]. > > Are these both correct assumptions? > > Perhaps it would make sense to pick a topic to share more details on the > list to get some discussion started - I assume the uni-directional approach > is a good place to start. It might help to summarize the flow, and the > implications of this change on the functionality and user experience. In > addition, Mounir, is it possible for you to share more on the list about > this topic from the Firefox OS point of view? > > Thanks > >regards, Frederick > > Frederick Hirsch, Nokia > Chair, W3C DAP Working Group > > [1] DAP F2F to be held in Düsseldorf, Germany 4-6 June 2013. > > On Mar 21, 2013, at 4:43 PM, ext Greg Billock wrote: > > Chrome (Greg Billock and Darin Fisher) and Mozilla (Jonas Sicking and > Mounir Lamouri) folks got together recently to talk about Web Intents/Web > Activities, and exchange information and ideas. Here's a summary, and some > food for thought about a direction forward: > > 1. We spent quite a bit of time discussing the issues with the Chrome > Web Intents experimental implementation that we discussed in TPAC -- the > difficulty of indicating cross-tab coordination and the state of that > coordination, difficulties with bidirectional communication given two > communicating contexts, etc. FirefoxOS is not dealing with a lot of these > issues with Web Activities -- the handler contexts tend to be > system-originated and replace existing UI. > > 2. We discussed ways to address these problems. The most promising soun > like limiting handlers to inline-only and/or restricting communication to > unidirectional-only. This handles many use cases and may provide a way to > ease some of the UI constraints. A possible direction is to enable > bi-directional communication through including a target URL in the > unidirectional invocation, such that the target is able to invoke to, for > example, save an edited document. > > 3. We discussed switching the governance of the disposition such that > the client always controls the disposition context. That is, source pages > would control whether the handler ran inline or in another > tabbed/overlapped context. This seems like a promising change -- it reduces > the unpredictability of the UI for clients. There's a question as to how > much disposition negotiation could occur that would need to be resolved. > This also allows a path to another embed-like disposition which acts more > like a plug-in. > > 4. We spent time talking about the right context in which to handle > invocations in a reduced scope -- should this be analogous to a shared > worker? But those don't have access to any DOM. Should they be analogous to > Chrome's event pages? Having a DOM is convenient, but is that convenience > worth the cost? > > 5. There's a possible ramp-up opportunity where we start with > inline/unidirectional data flow and see how far that takes us. Some of > these ideas give us confidence we're not trapped, and we can perhaps ease > our way past the most challenging UI problems. This direction is pretty > much the scope of what Mozilla is doing with Firefox OS, so we hope to > learn a lot from that. > > >
Re: Web Activities: counter-proposal to Web Intents
Thanks, Mounir. I've been reading the overview, and I have a lot of the same reactions Robin did to issues of scope. Based on what I read in the wiki and in this mail, the scope you have in mind is very similar to where I think we all agree the use cases of web intents predominately lie (edit, pick, share, view). The approaches of the APIs (RPC-style as opposed to mediated through postMessage, for example) are very similar. The mechanisms they use are are also functionally very similar: there's registration, there's invocation, there's delivery, there's response. I see an open action and type namespace, so that web developers are free to take advantage of the functionality to do things that we can't predict currently, and yes, so that other standards can use the functionality as a mechanism, in the same way it uses things like structured clone and eventing. All this makes me believe we have a very similar understanding of this problem and what is entailed in a responsive solution. I am optimistic that we'll figure out the technical details and come to consensus about the right API to expose this functionality to web developers. Moving to specifics of the API, I find a lot to like in this proposal. Invocation by scope closing is unintuitive, but using a Future-style object is appealing. That is, something like this: var futureValue = navigator.startActivity(intent payload); futureValue.onReply = handler; futureValue.onError = handler; In Web Intents, we used callbacks for this mechanism, since it ends up being more compact and also more idiomatic for web APIs. Still, IndexedDB makes good use of the Future style, and so do many popular JS libraries. One might wish the File/Filesystem API had taken a similar approach. The differences in service and intent parameters are mostly cosmetic. One excellent solution I found there to a longstanding problem, which we should adopt, is to include a "multiple=true" extras parameter to indicate that the client can handle (and therefore, that the service can produce), arrays of values in the return type. For delivery, I think utilizing a novel system message handler is less desirable than other evented mechanisms for delivery. There are a couple such that we should consider, however. When originally proposed, we specifically wanted to rule out multiple delivery to a particular context, which led us to the very simple "window.intent" mechanism. Our thinking now is that ruling this out is a mistake, and we need to provide a mechanism to deliver the intent payload as an event. I think the most unsurprising way to do this would be a window-based "intent" event. Another suggestion which Alex Russell made, and I think is really slick, is to deliver to an intent listener on the tag itself. This couples registration and handling in a very compelling fashion. For registration, I think Ian Hickson's proposal to consider web intents, registerProtocolHandler, and registerContentHandler, as all part of the same feature is the right direction. I prefer declarative to imperative registration, as I think it apportions responsibilities more cleanly and accurately, but it looks like at the end of the day we'll have both, and for good reasons. On Tue, Jun 12, 2012 at 7:08 AM, Mounir Lamouri wrote: > Hi, > > With some people at Mozilla, we've been working on an API similar to Web > Intents in some points but distant enough to be a counter-proposal. We > believe that the API is now in a good enough shape to be officially sent > in those mailing lists and discussed. > > You can have an overview of the API > here:https://wiki.mozilla.org/WebAPI/WebActivities > > Web Activities' intent is not to be a clone of Google's Web Intents with > some naming and API details changed. Web Activities aim to be a simple > API trying to solve a very clear set of use cases. > > It has been a bit hard to judge the desired scope of Web Intents. People > have suggested that Intents should be able to solve everything from > getting low-level Sensor information [1] to the ability to implement > services like Push Notifications [2] to doing discovery and control of > DVR hardware from the browser [3]. It is unclear if this is just a list > of things people wish that Intents could help with, or if these are hard > requirements that the spec authors are using to design the spec for. > > An API which allows building a wide range of applications is generally a > good API, however it is also important to have a concrete set of use > cases when designing an API to make sure that it solves those use cases > well. Our concern is that Intents are designed to solve the ambigious > use case of "communicating with anything". > > As a reminder, the basic use cases of Web Intents seem to be: "Users use > many different services on the web to handle their day to day tasks, > such as sharing images, editing documents and listening to music. They > expect their applications to be connected and to work together > seamles
Re: Publish FPWD of Web Intents spec; deadline June 12
Done. Thanks for the reality check. :-) On Wed, Jun 6, 2012 at 1:35 AM, Ms2ger wrote: > On 06/06/2012 02:26 AM, Greg Billock wrote: >> >> On Tue, May 29, 2012 at 10:48 PM, Deepanshu Gautam >> wrote: >>> >>> Please refer to the email thread below >>> >>> http://lists.w3.org/Archives/Public/public-web-intents/2012May/0054.html >>> >>> Where a consensus was reached to delete the following statement from the >>> Suggestions related text. >>> >>> "The User Agent should ignore the suggested services from the intent >>> invocation if the user already has a handler selected." >>> >>> I would like that statement to be delete before FPWD. >> >> >> This is done in my local version. I have a collection of edits that >> have been suggested as people have looked at the draft more closely. >> I've been holding off submitting them to maintain a stable version. >> Shall I go ahead and submit the edited version? > > > Please do; there's no point in holding off clear improvements. > > Thanks > Ms2ger >
Re: Publish FPWD of Web Intents spec; deadline June 12
On Tue, May 29, 2012 at 10:48 PM, Deepanshu Gautam wrote: > Please refer to the email thread below > > http://lists.w3.org/Archives/Public/public-web-intents/2012May/0054.html > > Where a consensus was reached to delete the following statement from the > Suggestions related text. > > "The User Agent should ignore the suggested services from the intent > invocation if the user already has a handler selected." > > I would like that statement to be delete before FPWD. This is done in my local version. I have a collection of edits that have been suggested as people have looked at the draft more closely. I've been holding off submitting them to maintain a stable version. Shall I go ahead and submit the edited version? > > Regards > > > Deepanshu Gautam > Senior Engineer, Service Standards, Huawei > O: +86 25 56620008 M: +8613585147627 > >> -Original Message- >> From: James Hawkins [mailto:jhawk...@google.com] >> Sent: Wednesday, May 30, 2012 2:45 AM >> To: WebIntents; public-webapps@w3.org; public-device-a...@w3.org >> Subject: CfC: Publish FPWD of Web Intents spec; deadline June 12 >> >> Dave Raggett (d...@w3.org) made a call [1] on April 10 to publish a >> first public working draft, and this is a Call for Consensus to do so, >> using the following document as the basis: >> >> >> >> I included public-webapps and public-device-apis on this CfC since Web >> Intents is a joint-deliverable [2][3] between these two groups. >> >> By publishing this FPWD, the group sends a signal to the community to >> begin reviewing the document. The FPWD reflects where the group is on >> this spec at the time of publication; it does not necessarily mean >> there is consensus on the spec's contents. >> >> Positive response to this CfC is preferred and encouraged and silence >> will be considered as agreement with the proposal. The deadline for >> comments is June 12. Please send all comments to: >> >> public-web-inte...@w3.org >> >> Thanks, >> James Hawkins >> >> [1] http://lists.w3.org/Archives/Public/public-web-intents/2012Apr/0016.html >> [2] http://www.w3.org/2012/webapps/charter/ >> [3] http://www.w3.org/2011/07/DeviceAPICharter >
Re: Draft Minutes: 1 May 2012 f2f meeting
Looks right to me. On Tue, May 8, 2012 at 10:23 AM, Arthur Barstow wrote: > On 5/8/12 1:11 PM, ext Arthur Barstow wrote: > > Greg, Tantek, All - I think there is an error in this part of the draft Web > Intents minutes: > > [[ > http://www.w3.org/2012/05/01-webapps-minutes.html#item06 > > > tantek:do you know about opendoc and ola? > ... systems for applications doing this. Have you looked at that? > > gbillock:nope > ... there is IPR in that area that should be looked at. > ... (I know because I did some of it) > ]] > > Only part of Greg's quote above should be attributed to him and the rest > should be attributed to Tantek. More specifically, here is what I believe is > what they said in this exchange: > > [[ > http://www.w3.org/2012/05/01-webapps-minutes.html#item06 > > > tantek:do you know about opendoc and ola? > ... systems for applications doing this. Have you looked at that? > > gbillock:nope > > tantek: there is IPR in that area that should be looked at. > > ... (I know because I did some of it) > ... I felt I had an obligation to make that disclosure > ]] > > Tantek, Greg and Others - what is your recollection on this exchange? Is my > correction above accurate? > > -Thanks, Art >
Re: Transferable and structured clones, was: Re: [FileAPI] Deterministic release of Blob proposal
On Tue, Mar 6, 2012 at 1:18 PM, Kenneth Russell wrote:
> On Tue, Mar 6, 2012 at 12:04 PM, Greg Billock wrote:
>> On Mon, Mar 5, 2012 at 6:46 PM, Charles Pritchard wrote:
>>> On 3/5/2012 5:56 PM, Glenn Maynard wrote:
>>>
>>> On Mon, Mar 5, 2012 at 7:04 PM, Charles Pritchard wrote:
>>>>
>>>> Do you see old behavior working something like the following?
>>>>
>>>>
>>>> var blob = new Blob("my new big blob");
>>>> var keepBlob = blob.slice(); destination.postMessage(blob, '*', [blob]);
>>>> // is try/catch needed here?
>>>
>>>
>>> You don't need to do that. If you don't want postMessage to transfer the
>>> blob, then simply don't include it in the transfer parameter, and it'll
>>> perform a normal structured clone. postMessage behaves this way in part for
>>> backwards-compatibility: so exactly in cases like this, we can make Blob
>>> implement Transferable without breaking existing code.
>>>
>>> See http://dev.w3.org/html5/postmsg/#posting-messages and similar
>>> postMessage APIs.
>>>
>>>
>>> Web Intents won't have a transfer map argument.
>>> http://dvcs.w3.org/hg/web-intents/raw-file/tip/spec/Overview.html#widl-Intent-data
>>>
>>> For the Web Intents structured cloning algorithm, Web Intents would be
>>> inserting into step 3:
>>> If input is a Transferable object, add it to the transfer map.
>>> http://www.whatwg.org/specs/web-apps/current-work/multipage/common-dom-interfaces.html#internal-structured-cloning-algorithm
>>>
>>> Then Web Intents would move the first section of the structured cloning
>>> algorithm to follow the internal cloning algorithm section, swapping their
>>> order.
>>> http://www.whatwg.org/specs/web-apps/current-work/multipage/common-dom-interfaces.html#safe-passing-of-structured-data
>>>
>>> That's my understanding.
>>
>> We've been discussing the merits of this approach vs using a transfer
>> array argument. There's a lot to like about this alternative -- it
>> conserves arguments and looks simpler than the transfer map, as well
>> as not having the headaches of whether you can do (null, [port]) or
>> (port, [port]) and concerns like that.
>>
>> The advantage of using the transfer map param is that it is more
>> contiguous with existing practice. We'd kind of hoped that this
>> particular debate was finalized before we got to the point of needing
>> to make a decision, so we bluffed and left it out of the web intents
>> spec draft. :-) At this point, I'm leaning toward needing to add a
>> transfer map parameter, and then dealing with that alongside other
>> uses, given the state of thinking on Transferables support and the
>> need to make this pretty consistent across structure clone
>> invocations.
>>
>> I do think that complexity might be better solved by the type system
>> (i.e. a "new Transferable(ArrayBuffer)"), which would require a
>> different developer mechanic to set up clone vs transfer, but would
>> relieve complexity in the invocation of structured clone itself:
>> transferables could just always transfer transparently. I don't know
>> if, given current practice with MessagePort, that kind of solution is
>> available.
>
> A change like this would be feasible as long as it doesn't break
> compatibility. In other words, the current Transferable array would
> still need to be supported, but Transferable instances (or perhaps
> instances of some other type) wrapping another Transferable object
> would also express the intent.
>
> The current API for Transferable and postMessage was informed by the
> realization that the previous sequence argument to
> postMessage was essentially already expressing the Transferable
> concept.
>
> I'm not familiar with the Web Intents API, but at first glance it
> seems feasible to overload the constructor, postResult and postFailure
> methods to support passing a sequence as the last
> argument. This would make the API look more like postMessage and avoid
> adding more transfer semantics. Is that possible?
Yes. That's our current plan.
-Greg
Re: Transferable and structured clones, was: Re: [FileAPI] Deterministic release of Blob proposal
On Mon, Mar 5, 2012 at 6:46 PM, Charles Pritchard wrote:
> On 3/5/2012 5:56 PM, Glenn Maynard wrote:
>
> On Mon, Mar 5, 2012 at 7:04 PM, Charles Pritchard wrote:
>>
>> Do you see old behavior working something like the following?
>>
>>
>> var blob = new Blob("my new big blob");
>> var keepBlob = blob.slice(); destination.postMessage(blob, '*', [blob]);
>> // is try/catch needed here?
>
>
> You don't need to do that. If you don't want postMessage to transfer the
> blob, then simply don't include it in the transfer parameter, and it'll
> perform a normal structured clone. postMessage behaves this way in part for
> backwards-compatibility: so exactly in cases like this, we can make Blob
> implement Transferable without breaking existing code.
>
> See http://dev.w3.org/html5/postmsg/#posting-messages and similar
> postMessage APIs.
>
>
> Web Intents won't have a transfer map argument.
> http://dvcs.w3.org/hg/web-intents/raw-file/tip/spec/Overview.html#widl-Intent-data
>
> For the Web Intents structured cloning algorithm, Web Intents would be
> inserting into step 3:
> If input is a Transferable object, add it to the transfer map.
> http://www.whatwg.org/specs/web-apps/current-work/multipage/common-dom-interfaces.html#internal-structured-cloning-algorithm
>
> Then Web Intents would move the first section of the structured cloning
> algorithm to follow the internal cloning algorithm section, swapping their
> order.
> http://www.whatwg.org/specs/web-apps/current-work/multipage/common-dom-interfaces.html#safe-passing-of-structured-data
>
> That's my understanding.
We've been discussing the merits of this approach vs using a transfer
array argument. There's a lot to like about this alternative -- it
conserves arguments and looks simpler than the transfer map, as well
as not having the headaches of whether you can do (null, [port]) or
(port, [port]) and concerns like that.
The advantage of using the transfer map param is that it is more
contiguous with existing practice. We'd kind of hoped that this
particular debate was finalized before we got to the point of needing
to make a decision, so we bluffed and left it out of the web intents
spec draft. :-) At this point, I'm leaning toward needing to add a
transfer map parameter, and then dealing with that alongside other
uses, given the state of thinking on Transferables support and the
need to make this pretty consistent across structure clone
invocations.
I do think that complexity might be better solved by the type system
(i.e. a "new Transferable(ArrayBuffer)"), which would require a
different developer mechanic to set up clone vs transfer, but would
relieve complexity in the invocation of structured clone itself:
transferables could just always transfer transparently. I don't know
if, given current practice with MessagePort, that kind of solution is
available.
> Something like this may be necessary if Blob were a Transferable:
> var keepBlob = blob.slice();
> var intent = new Intent("-x-my-intent", blob);
> navigator.startActivity(intent, callback);
>
>> And we might have an error on postMessage stashing it in the transfer
>> array if it's not a Transferable on an older browser.
>
>
>
>
> Example of how easy the neutered concept applies to Transferrable:
>
> var blob = new Blob("my big blob");
> blob.close();
>
>
> I like the idea of having Blob implement Transferrable and adding close to
> the Transferrable interface.
> File.close could have a better relationship with the cache and/or locks on
> data.
>
>
> Some history on Transferrable and structured clones:
>
> Note: MessagePort does have a close method and is currently the only
> Transferrable mentioned in WHATWG:
> http://www.whatwg.org/specs/web-apps/current-work/multipage/common-dom-interfaces.html#transferable-objects
>
> ArrayBuffer is widely implemented. It was the second item to implement
> Transferrable:
> http://www.khronos.org/registry/typedarray/specs/latest/#9
>
> Subsequently, ImageData adopted Uint8ClampedArray for one of its properties,
> adopting TypedArrays:
> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#imagedata
>
> This has lead to some instability in the structured clone algorithm for
> ImageData as the typed array object for ImageData is read-only.
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=13800
>
> ArrayBuffer is still in a strawman state.
>
> -Charles
>
>
Re: Web Messaging Intents, was: Re: [DRAFT] Web Intents Task Force Charter
On Mon, Nov 14, 2011 at 7:24 PM, Charles Pritchard wrote: > ** > Does anybody use registerProtocolHandler in any real sense? Is > registerContentHandler needed? It seems like Web Intents is an evolution on > the concept. I don't think we're going to see convergence on those old > methods. I'm ready to leave them both in favor of a yet-to-be announced > candidate (web intents). > > URIs are better than protocols, and Intents are better than content > handlers. In my opinion. > RPH seems to be intended primarily for mailto: (I think that's where it is used.) I'm not sure what the RCH usage is like. It is definitely possible to imagine mapping UA handling of mailto: onto web intents. The way I think of it is like this: RPH is basically an action with a payload. RCH is essentially type info with the payload. Web Intents is kind of off-axis with both an action and a type as well as the payload. The idea (taking inspiration from the pluggable usage in the Android ecosystem) is that the action (analogous to the "protocol") is a locus between the client and handling service which can be messaged to the user in a well-understood way. (i.e. instead of just saying "here's some data, do whatever you want with it," which is a more content-type-driven As far as I can tell, the model doesn't prohibit, nor does it encourage, > the passing of MessageChannel. > It's very much made for an RPC style of communication, but if the message > being passed back is a channel, well that's just fine. > > Am I mistaken? What I'm seeing is that we get MessageChannel for free, and > there's no need to specify further. > Individual Intent authors can do that themselves. > Yes. We envision RPC-style request/response as the sweet spot for intents. We've definitely considered use cases which are better served by opening a persistent channel. It isn't clear to me as yet what to do about those. They definitely imply a more well-specified protocol to be pursued over that channel. Web Intents as an API doesn't really include or exclude that in the current form. On the other hand, it'd be a really nice application of the Web Intents permissions mechanism to be able to connect up, say, an SSH connection using Web Intents, so that I could write an in-browser terminal which could then be attached to a secure socket by the user. At this point, I'm not sure whether this kind of persistent connection use case is far enough from Web Intents to want to exclude it, or close enough to want to include it explicitly. Our early belief is that we aren't ruling it out with the proposed API, since MessageChannels could be provided or returned in the payload data. On the other hand, we haven't chosen to explicitly include such usage. But a lot of this stuff just comes with nice platform integration; I just tried passing Blob objects through intents in Chrome Tip-of-Tree with our prototype, and it Just Works, allowing a really appealing vision into what "upload" intents and file interactions could be like. Wins like that make me think that focusing on the sweet spot RPC interaction will not paint us into a corner. -Greg
Re: [DRAFT] Web Intents Task Force Charter
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.
