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< On Fri, Nov 7, 2014 at 8:57 AM, Mounir Lamouri <mou...@lamouri.fr> wrote: > (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 > >
