RE: Messaging API and URI schemes (ISSUE-107)

Hi Niklas,

Le jeudi 10 février 2011 à 15:13 +0100, Niklas Widell a écrit :
> Revisiting an old thread (based on yesterday's discussion), I think
> the main/only reason to spell out messaging technology had to do with
> security, being able to map permissions to method names. 

While tying permission to method names is one method (and one the BONDI
policy framework relied on), it is not necessarily the only one
available. If we used an API that relied on URI schemes as parameter,
one could easily imagine that the clients would adapt their security
mechanisms to the targeted URI scheme (the same way browsers already
behave differently with file: and http:).

> While I certainly still see the need for being messaging technology
> agnostic, as well as benefit in aligning technology naming with
> existing scheme names, I don't really understand how relying on the
> URI schemes makes things so much better than having msg.create(type,
> to, ...), msg.setParameter(...) and msg.send() but I'm probably
> missing the point here.

I think the difference between msg.create(type) vs msg.create(uri) is
mostly cosmetic, but one clear advantage is that you don't need to add a
new constant to handle a new message type, you "only" need to rely on a
related URI scheme.

More abstractly, relying on an existing system that enables
extensibility saves us from having to specify our own.

> Regarding Rich's final (no specific messaging API at all) solution,
> that might work, but wouldn't it also just move the headache to the
> developer instead? In particular if device local access is needed?

Yes, I agree that access to messaging services that are not exposed as
Web services more or less require a specific API.

Dom

Received on Thursday, 10 February 2011 16:05:08 UTC