Re: [Execution and Security Model] Proposal from Samsung Electronics

Hi,

First of all, I am sorry that it took so long before my reply. I had a
ton of stuff to do on other topics. I will do my best to dedicate more
time for this WG in the future.

I think this proposal is a great initiative. It is very good to have two
proposals to start a discussion. Thank you for that :)

I read the proposal and wrote a few comments (mostly stuff that pop up
while reading, nothing very deep). Given that there is another thread
about the relation between Mozilla's proposal and Samsung's proposal, I
will leave that for the other thread.

* Application service *

I think mentioning this is confusing. It is better to let the
specification (Web Intents, Web Activities or whatever the name happen
to be) that will handle that simply plug itself to the manifest format.

* System Applications *

It is not very clear if this specification takes care of the hosted
applications and packaged applications or only the later. There is a
clear mention of the ability to install an application without a package
but every thing seems to be written with a package in mind. Or maybe I'm
biased because my vision of the non-packaged application is different
from the vision this specification has.
Also, the name of "system application" is a bit confusing [to me]. I
think the name of "hosted applications" and "packaged applications" as
chosen by Mozilla [1] and Google [2][3] is better. This said, Mozilla
uses "web application" as a generic name and we should probably call
those "installed web applications".

* Update *

I do not think we should make the version meaningful. It is way too hard
to have good heuristics for version numbers and if we don't use
heuristics, apps might break because they will not follow the convention
of the specifications. In addition, the web doesn't have any concept of
version and we should just follow that trend and keep "version" as
informational.

* Runtime interface *

Adding 'name', 'version', 'platform' and 'application' directly to the
Window object seems a bit optimistic. Given that those attributes will
be in the global scope, it is very likely that they will end up
conflicting with something else at some point.
Also, it is not clear why we need 'name', 'version' and 'platform'. This
is information the navigator object should already have.

* Application interface *

I think this is very similar to our Application interface. There are a
few differences. For example, you guys added an id while we consider the
'manifestURL' to be the unique identifier of the application.
Why do you happen to need an explicit id?

Also, .show and exit() could be replaced by already existing API in the
Web: window.close() (for .exit()) and document.hidden (for .show).

* Origin *

We have a very similar approach regarding origin in our proposal but
only for packaged applications. We consider that hosted applications
should simply use the origin of their manifest.

* Execution Model *

This is an interesting part because it is not much considered in our
specification. The only mention we have is that an application MAY be
put in a paused state when not showing.

As "ISSUE 2" pointed out, I am not sure that there is a real world usage
for a "launch" event. In addition, it is very hard to define a DOM event
that has to be sent before load or DOMContentLoaded events because that
mean that the handler has to be set before the event being fired but
technically the event could be fired at any moment... This is the main
reason why we created System Mesages. Note that if we really need to, we
can create a "start" System Message.

The purpose of the "request" event isn't clear to me either. What are
the use cases?

Regarding 'terminate', I wonder how much we can try to use existing
events like 'unload'.

For 'pause'/'resume', I think this is a wide discussion because we need
to define if it is possible to put an application in pause at arbitrary
times (if possible at all). I don't have a strong opinion yet on the
subject. That is why I put in our spec that this MAY be possible. For
the moment Firefox OS doesn't do that but I think the expected behaviour
should be specified because applications will need to know if they can
be paused and in which situations.

* RuntimeExecutionManager interface *

What exactly is expected to use this interface? I feel like this is
something more on the system side. For example, I do not really expect
any application to be able to call .pause() or .resume() but I would
expect the user agent to handle that.

* Security model *

The fact that you guys have three levels of security instead of two is
interesting. What use cases did you had in mind?
(Actually, we also have three levels of security but the third one is
more or less a "chrome-only" level which is mostly to not allow access
to something so it's more an implementation detail.)

[1]
http://mounirlamouri.github.com/sysapps/proposals/RunTime-Security/Overview.html
[2] https://developers.google.com/chrome/apps/docs/developers_guide
[3] https://developer.chrome.com/extensions/apps.html

Cheers,
--
Mounir

Received on Friday, 15 February 2013 18:36:12 UTC