Re: New approach to activities/intents

Right.

Didn't we have a problem with Canvas's string-based getContext already?

http://robert.ocallahan.org/2012/05/canvas-getcontext-mistake.html

/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
>

Received on Tuesday, 11 November 2014 01:34:15 UTC