ubuntu-phone team mailing list archive

[Rasmus Eneman <Rasmus@xxxxxxxxx>]

>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 <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
>
>
> --
> Mailing list: https://launchpad.net/~ubuntu-phone
> Post to     : ubuntu-phone@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ubuntu-phone
> More help   : https://help.launchpad.net/ListHelp
>
>


-- 
Rasmus Eneman