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
signature.asc
Description: This is a digitally signed message part
-- 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
