ubuntu-phone team mailing list archive

[Ted Gould <ted@xxxxxxxxxx>]

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

Attachment: signature.asc
Description: This is a digitally signed message part