>Along with allowing applications to define more URIs, we'll need to mediate between them. For instance you register for "http://*facebook.com/*"; and so does the official Facebook app... what to do. I consider figuring out that as part of the work above. Ideas welcome :-)
I think this is one of those things Android does very good. Just fire up a dialog that lets you choose which one to use and if that should be remembered or not. Can't be much more simple than that. 2013/9/19 Ted Gould <t...@ubuntu.com> > ** > On Wed, 2013-09-18 at 15:58 -0400, Alexandre Abreu wrote: > > It might be a little pedantic, but shouldn't we talk about URI instead of > URL? > > > Yeah, that is a little pendantic :-) Perhaps, but I think for most people > they're synonymous. > > > Besides that a few questions: > > > - Is APP_ID going to be used in e.g. the proposed URI > application://$(APP_ID).desktop (why specify the ".desktop" btw?), by that > I mean w/ the version included? > > > The application URI that we took there is one that Zeitgeist was already > using and we just went with it. They required that in the original > version. I do plan to have a different URI that allows for "wildcards" in > the App ID, but that's not done yet. More info as I have something to > share. > > > - I guess that it will work in some sort of "fire and forget" fashion, > not really giving any guarantees or error mechanisms? > > > For the most part. We do return a simple error so that you can do some > handling of the error if need be. There are a lot of levels of error. We > only return the errors that relate to finding a match for the URI, if the > application fails to start or segfaults we don't pass that back through. > > > - Will one be able to pass down parameters to the app thru the URI? if > yes, I guess that will there be a mechanism , > > > URL Dispatcher doesn't care. That's between the caller and callee. I'm > pretty sure the addressbook:// format we added today has a lot of > flexibility there, but I'll let those guys say more. > > > - How an app is supposed to be "wired" when it wants to basically respond > to those, will it start an new target app instance or will it hook up to > whatever mechanism in the applications' message dispatch loop? > > > Today the only thing we're doing is passing them where ever you put a "%u" > in your Exec line in the desktop file. In the future we hope to send them > over DBus to applications as well if they're already running. That's a > TODO, and yet undefined. Definitely important, trying to get everyone on > that. > > > - Will the URI list be static? > > > Short term, yes. Long term, no. I really don't want to be the guy > maintaining the list of URIs, that's a crummy job :-) It's much better to > outsource that to the application developers. But that'll require adding > support to the Click manifest and putting in hooks and such. I really want > to get to that, but considering the list of TODOs right now, I'm not > optimistic it'll be soon. > > > - I know that we briefly touch the subject last week in a meeting, but > any plans for a hook mechanisms for those URI dispatches? e.g. I want my > app to place a hook in the URLdispatcher to handle specific URL schemes or > sub schemes, etc. before it reaches the fallback app, > > > Along with allowing applications to define more URIs, we'll need to > mediate between them. For instance you register for "http://* > facebook.com/*" and so does the official Facebook app... what to do. I > consider figuring out that as part of the work above. Ideas welcome :-) > > Ted > > > -- > Mailing list: https://launchpad.net/~ubuntu-phone > Post to : ubuntu-phone@lists.launchpad.net > Unsubscribe : https://launchpad.net/~ubuntu-phone > More help : https://help.launchpad.net/ListHelp > > -- Rasmus Eneman
-- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
