HI, Gustavo
Thanks. Sounds nice.
For Android, if the format is not defined as C++ class but manifest Json
format, whether it is accepted？
Of course, the format field representations of android can follow the
unified ones from Tizen and Chromium,
only the implementation of representations is different.
Best regards
David
-----Original Message-----
From: Barbieri, Gustavo
Sent: Friday, October 11, 2013 11:37 PM
To: Liu, David
Cc: Ming, Bai; crosswalk-dev@lists.crosswalk-project.org
Subject: Re: [Crosswalk-dev] Crosswalk API permissions and requirements
On Fri, Oct 11, 2013 at 12:12:16PM -0300, Liu, David wrote:
> It seems we are supposing
> 1 No format's conflicts between Tizen, Chromium and Android
They are different formats, we should handle them differently. Of course they
can get the same internal representation, but they need to be handled
differently based on file name/extension or contents.
> 2 Tizen can cover all the formats of Chromium and Android
Likely, but sooner or later we'll find something that is not covered. So we
need our own internal representation that is independent. We can start mapping
1:1 Tizen to our repr, since it seems to be pretty decent.
> 3 We need to indicate the platform-type due to the format difference.
> Need to decide whether the above are appropriate.
Yes, That's required at some level.
> Any misunderstanding, please feel free to correct me. Thanks
You seem to get it right. I'd do the following myself:
- create a Crosswalk representation (no need for a file format, only
C++ classes) that represents the entry points, features and
permissions.
- create different parsers/extractors based on file name, extension
and contents. If we see a "crx" we use Chromium extractor, if we
see "wgt" we use another. If formats use the same name but
differentiate in the XML namespace, then we need to decide later
on.
- each parser will instantiate and populate the crosswalk
representation, converting as needed. It may be useful to
tag/annotate the origin for future reference, however I don't see
the need for it now, let's evaluate it after we have some
implementation to test.
For instance when we reach a mature state we may have different Bluetooth
implementations: W3C, Chromium and Tizen. When you're parsing a chromium (crx)
application and you see "bluetooth" you convert both the permission and the
required extension so it won't load W3C or Tizen backends, just the Chromium
one. OTOH if you see a Tizen application requesting bluetooth.gap you check the
permissions and only expose Tizen bluetooth, not W3C or Chromium, etc.
What do you think?
--
Gustavo Sverzut Barbieri
Intel Open source Technology Center
_______________________________________________
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev
