Re: New approach to activities/intents

On Mon, Nov 10, 2014 at 5:33 PM, Brendan Eich <brendan@secure.meer.net>
wrote:

> Right.
>
> Didn't we have a problem with Canvas's string-based getContext already?
>
> http://robert.ocallahan.org/2012/05/canvas-getcontext-mistake.html


Domenic's question still needs addressing separately, but just a quick
response here -- the API roc described there is different. Tubes are just
like talking to a worker or any MessagePort. There is no extra API surface
emerging from getContext-like function call.

:DG<


>
>
> /be
>
>  Domenic Denicola <mailto:d@domenic.me>
>> November 10, 2014 at 6:14 PM
>> From: Dimitri Glazkov [mailto:dglazkov@google.com]
>>
>>
>> Can you help us understand the advantages of a string-based proprietary
>> APIs over a functions-and-objects proprietary APIs? We've had the latter
>> for many years with vendor prefixes, so what are the advantages of putting
>> them behind navigator.connect?
>>
>> navigator.connect seems great just for talking to foreign service workers
>> (in fact it can be the basis for a very general and powerful intents
>> system). But from what I can understand it's serving two masters: talking
>> to service workers built on standards that run in any browser, and also
>> talking to virtual "service workers" that implement proprietary
>> string-based APIs using "URLs" that only work in certain browsers. I don't
>> understand how these are connected... Hope you can help me out there :)
>>
>> Dimitri Glazkov <mailto:dglazkov@google.com>
>> November 10, 2014 at 12:45 PM
>> On Mon, Nov 10, 2014 at 1:38 AM, Anne van Kesteren <annevk@annevk.nl
>> <mailto:annevk@annevk.nl>> wrote:
>>
>>     On Fri, Nov 7, 2014 at 7:01 PM, Dimitri Glazkov
>>     <dglazkov@google.com <mailto:dglazkov@google.com>> wrote:
>>     > FWIW, I think we should be concentrating on something like the
>>     Tubes (aka
>>     > navigator.connect): https://github.com/dglazkov/tubes
>>     >
>>     > It is hard to impossible to get these types APIs right on the
>>     first try.
>>     > That's why we need to create a clearinghouse for capability
>>     experiments and
>>     > be data-driven in designing the right API.
>>
>>     It's still not clear to me what the advantage is of creating a
>>     framework for designing proprietary APIs.
>>
>>
>> If we don't do something like this as a platform, we'd be always lagging
>> behind. Many new ideas start as proprietary. It takes time for these ideas
>> to take shape and travel toward larger acceptance -- or die.  Instead of
>> shunning these ideas until they mature -- and thus effectively shut the
>> door to any innovation, we should embrace them and give them a place in the
>> platform.
>>
>> Take http://www.intel.com/content/www/us/en/architecture-and-
>> technology/realsense-overview.html as an example. It's unclear whether
>> this will lead to anything great. It's even less clear what the Web
>> platform API should look like, or whether this will every result on a
>> standard API. However, if we wait until clarity, we as a platform would
>> lose the ability to participate in the virtuous innovation cycle and, as a
>> result, lose more developer mindshare.
>>
>> FWIW, it is perfectly reasonable for us to admit that we as a platform
>> aim to always be years behind other platforms. But then we should make this
>> clear and communicate it to developers who keep trying to not give up on
>> the Web as a viable modern development platform.
>>
>> :DG<
>>
>>
>>
>>     --
>>     https://annevankesteren.nl/
>>
>>
>> Anne van Kesteren <mailto:annevk@annevk.nl>
>> November 10, 2014 at 4:38 AM
>>
>> It's still not clear to me what the advantage is of creating a
>> framework for designing proprietary APIs.
>>
>>
>> Dimitri Glazkov <mailto:dglazkov@google.com>
>> November 7, 2014 at 1:01 PM
>> FWIW, I think we should be concentrating on something like the Tubes (aka
>> navigator.connect): https://github.com/dglazkov/tubes
>>
>> It is hard to impossible to get these types APIs right on the first try.
>> That's why we need to create a clearinghouse for capability experiments and
>> be data-driven in designing the right API.
>>
>> :DG<
>>
>>
>> Mounir Lamouri <mailto:mounir@lamouri.fr>
>> November 7, 2014 at 11:57 AM
>>
>> (I realise that my reply went to public-webapps instead of whatwg, not
>> sure why. I will blame my email client :))
>>
>> On Fri, 7 Nov 2014, at 20:36, Anne van Kesteren wrote:
>>
>>> Wouldn't be worth experimenting first with a list of predefined share
>>>> endpoints (that you anyway might want to have) and see if the feature is
>>>> actually something that users are looking for?
>>>>
>>> We have something like that in Firefox Nightly. Apple ships something
>>> similar in Safari. Both can be extended through proprietary APIs.
>>>
>>
>> I think it would be great if Mozilla could keep track of the usage of
>> this feature and share that data.
>>
>>  Furthermore, wouldn't
>>>> that make sense to have a similar mechanism than Open Search and have a
>>>> way for a website to advertise its share endpoint(s)? Maybe the Manifest
>>>> could be a good use for that. Generally speaking, I see a lot of common
>>>> aspects between Open Search and this proposal.
>>>>
>>> Maybe. It would be even less flexible and depend even more on user
>>> interface innovation from the user agent.
>>>
>>
>> I don't think the issue here is flexibility. It's extensibility. You
>> want website to be able to advertise themselves in that list. Thus,
>> websites will only try to do so if they see a benefit in doing that, in
>> other words, if that feature is actually used by Firefox users.
>>
>> As a side note, I don't think that innovation always need to come from
>> new APIs. That feature sounds like a great opportunity to innovate
>> within the browser UI then iterate with an API.
>>
>> -- Mounir
>>
>>