Re: Feedback on the WebActivities API

[Mounir Lamouri]

On 16/11/12 12:59, David Bruant wrote:
> Hi,
>
> Feedback relates to https://wiki.mozilla.org/WebAPI/WebActivities
>
> Linking back to the comment in another thread, if one part of the API is
> async, all of it should be.
> partial interface Navigator {
> DOMRequest registerActivityHandler(ActivityHandlerDescription d);
> void unregisterActivityHandler(ActivityHandlerDescription d);
> bool isActivityHandlerRegistered(ActivityHandlerDescription
> handler);
> }
>
> If registering is an async operation, so should be unregistering and
> checking if something is registered should be too.
> isActivityHandlerRegistered returning a boolean means that this
> operation is doing some blocking IO in the main thread which is rather
> undesirable.

isActivityHandlerRegistered() being async would be so painful. We think
it's up to the UA to make sure this is fast.
We saw no reason to have unregisterActivityHandler being async.

> " Arguments for {un,}registerActivityHandler and
> isActivityHandlerRegistered
> You do not need to pass the same ActivityHandlerDescription object to
> have registerActivityHandler, unregisterActivityHandler and
> isActivityHandlerRegistered working. You only need to pass an instance
> of ActivityHandlerDescription with the same attribute values. "
> => My API red alarm went off. This is extremely error prone in my
> opinion. What if you don't pass an attribute? Do you need to not pass it
> or is passing undefined fine? null? For "same attribute value", what do
> you do of NaN and +0 and -0?
> Filters is an object, I guess the "structural equality" is recursive?
> What if register with a custom attribute of my own?

I haven't really understood your point. Passing the exact same object
(in opposition to an object with the same values) wouldn't work if your
register at a given moment and unregister at another mament with a one
restart in between.

> Is it possible to register 2 activity handlers with the same name? with
> the same name and different disposition? 4 handlers with same name and
> all combinations of disposition and returnValue?
> The problem I see with this API is that a registered activity is
> identified with a complex combination of several factors.

It is possible to register different activities with the same name as
long as they have different filters. This said, that might require some
more work because we might end up with two filters allowing the handling
for the same app.

> What about the following:
> First off, one has to notice that registerActivityHandler(desc).value is
> unused. We could have registerActivityHandler return a DOMRequest for an
> identifier. unregisterActivityHandler and isActivityHandlerRegistered
> would take an identifier as argument. The application is free to store
> the identifier in a IDB database or whatever. Arguably, instead of
> isActivityHandlerRegistered we could have a method that given an
> identifier return a DOMRequest for an ActivityHandlerDescription

What if the app got it's IndexdDB wiped off? It will try to re-register,
right?

> I don't understand why the returnValue boolean is for. What's wrong with
> considering that it always return a value?

That's for UI issues. It was required to be able to give a good UX and
some API behaviour. As you can imagine, there is a huge difference
between a 'view' activity, that would simply open the gallery app and an
edit activity that will return the edited image. That has been discussed
already in dev-webapi I think.

> "filters: this object should mirror data from ActivityOptions but the
> values for each fields can be an Array of string, a string or a regexp."
> => I think an array of RegExp would be nice too. Sure you can express
> several RegExps in one, but what you end up doing is express several
> small maintanable RegExps into one monster RegExp.

Why not. But actually, RegExp is problematic because you can't use
RegExp in JSON which makes the declarative registration not able to use
RegExp and we can't expect activity handlers to use the programmatic way
if they want to use RegExp to filter.

Generally speaking, you should note that we haven't implemented
register/unregister/isregistered in Firefox OS for the moment.
Also, the filtering is know to be under-efficient and has to be fixed.

Cheers,
--
Mounir

[David Bruant]

Le 20/11/2012 15:22, Mounir Lamouri a écrit :
> On 16/11/12 12:59, David Bruant wrote:
>> Hi,
>>
>> Feedback relates to https://wiki.mozilla.org/WebAPI/WebActivities
>>
>> Linking back to the comment in another thread, if one part of the API is
>> async, all of it should be.
>> partial interface Navigator {
>> DOMRequest registerActivityHandler(ActivityHandlerDescription d);
>> void unregisterActivityHandler(ActivityHandlerDescription d);
>> bool isActivityHandlerRegistered(ActivityHandlerDescription
>> handler);
>> }
>>
>> If registering is an async operation, so should be unregistering and
>> checking if something is registered should be too.
>> isActivityHandlerRegistered returning a boolean means that this
>> operation is doing some blocking IO in the main thread which is rather
>> undesirable.
> isActivityHandlerRegistered() being async would be so painful. We think
> it's up to the UA to make sure this is fast.
> We saw no reason to have unregisterActivityHandler being async.

Why isn't it up to the UA to make sure registerActivityHandler is fast?
Regardless, what if the UA fails at making it fast? If you can make it
fast, sync or async doesn't matter. If you can't async is the safe bet.

>> " Arguments for {un,}registerActivityHandler and
>> isActivityHandlerRegistered
>> You do not need to pass the same ActivityHandlerDescription object to
>> have registerActivityHandler, unregisterActivityHandler and
>> isActivityHandlerRegistered working. You only need to pass an instance
>> of ActivityHandlerDescription with the same attribute values. "
>> => My API red alarm went off. This is extremely error prone in my
>> opinion. What if you don't pass an attribute? Do you need to not pass it
>> or is passing undefined fine? null? For "same attribute value", what do
>> you do of NaN and +0 and -0?
>> Filters is an object, I guess the "structural equality" is recursive?
>> What if register with a custom attribute of my own?
> I haven't really understood your point. Passing the exact same object
> (in opposition to an object with the same values) wouldn't work if your
> register at a given moment and unregister at another mament with a one
> restart in between.

True. I had misunderstood this aspect. Thanks for the explanation.
It doesn't make any less true that structural equality is a complex
problem. Does the "disposition" matter in this value equality? If it's
inherited? non-enumerable? These questions shouldn't matter and whatever
implementation choice has been made impacts how people can use the APIs
while it shouldn't.

One idea to make things easier for everyone would be for the app
developer to choose an id (string) and reuse it in the app code.
If no "id" value is provided, the name is used as the id. If an "id"
value is provided, this is what is used to identify the activity. With a
serialized identifier (instead of object identity), there is no restart
issue.

This id would just be used in
register/unregister/isRegisteredActivityHandler. The activity delegation
would still use name+filters.

>> Is it possible to register 2 activity handlers with the same name? with
>> the same name and different disposition? 4 handlers with same name and
>> all combinations of disposition and returnValue?
>> The problem I see with this API is that a registered activity is
>> identified with a complex combination of several factors.
> It is possible to register different activities with the same name as
> long as they have different filters.

I wonder how that would look like in the JSON declarative form... Maybe
the "activities" field in the manifest needs to be changed to an array.

> This said, that might require some
> more work because we might end up with two filters allowing the handling
> for the same app.

That is an issue indeed.

>> What about the following:
>> First off, one has to notice that registerActivityHandler(desc).value is
>> unused. We could have registerActivityHandler return a DOMRequest for an
>> identifier. unregisterActivityHandler and isActivityHandlerRegistered
>> would take an identifier as argument. The application is free to store
>> the identifier in a IDB database or whatever. Arguably, instead of
>> isActivityHandlerRegistered we could have a method that given an
>> identifier return a DOMRequest for an ActivityHandlerDescription
> What if the app got it's IndexdDB wiped off? It will try to re-register,
> right?

All true.
Developer-chosen ids are a solution to this issue.

>> "filters: this object should mirror data from ActivityOptions but the
>> values for each fields can be an Array of string, a string or a regexp."
>> => I think an array of RegExp would be nice too. Sure you can express
>> several RegExps in one, but what you end up doing is express several
>> small maintanable RegExps into one monster RegExp.
> Why not. But actually, RegExp is problematic because you can't use
> RegExp in JSON which makes the declarative registration not able to use
> RegExp and we can't expect activity handlers to use the programmatic way
> if they want to use RegExp to filter.

There are solutions to express regexps based on string. People do it
when they use the RegExp constructor [1]. I won't say it's a fantastic
idea, but it's not that awful.

> Generally speaking, you should note that we haven't implemented
> register/unregister/isregistered in Firefox OS for the moment.

oh ok. I haven't tried these methods yet :-p Do you have a bug number
for this part?

> Also, the filtering is know to be under-efficient and has to be fixed.

And a bug number related to this part?

David

[1] http://es5.github.com/#x15.10.4.1