incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Brooks <mich...@michaelbrooks.ca>
Subject Re: Cordova and config.xml
Date Tue, 29 May 2012 18:26:13 GMT
@Fil thanks for pointing out the Mozilla's App Manfiest!

@Ken I think prudent that Apache Cordova listen to BlackBerry's experience
with the widget spec. We're both using it in similar ways and Apache
Cordova will likely hit the same areas for customization. Ken, can you
elaborate on how BB10 will be deviating even further? Is there a link out
there?

Regardless of what we choose, we don't want to invent our own app manifest
"standard" and so it's worth reviewing the two that are out there. Below
are the spec links.

W3C Configuration Document (config.xml):
http://www.w3.org/TR/widgets/#configuration-document

BlackBerry WebWorks config.xml:
https://developer.blackberry.com/html5/documentation/ww_developing/working_with_config_xml_file_1866970_11.html

Mozilla App Manifest:
https://developer.mozilla.org/en/Apps/Manifest

Michael

On Tue, May 29, 2012 at 11:13 AM, Ken Wallis <kwallis@rim.com> wrote:

> Laurent and I were just chatting about this.  Certainly feel that we
> should have a common shared format for application metadata.  Default
> option would be to look at the W3C widget spec which we all are or already
> have done in RIM's case. ;)
>
> That said, you know that we have gone past the spec already, and with BB10
> we will have to go even farther down the custom namespace route.  We (RIM)
> may need to actively diverge on some concepts that might have Widget
> equivalents but just don't map properly (Not sure yet, but starting to get
> a feeling...)  I would suspect that Cordova will need custom elements as
> well.
>
> Do we ask the question then, is this still the right choice, use widget
> spec as a basis and expand where needed?  Use it as inspiration, but not be
> beholden to it?  Something completely custom, or aligned with other
> initiatives like Mozilla?
>
> Lots of questions... ;)
> --
>
> Ken Wallis
>
> Product Manager – BlackBerry WebWorks
>
> Research In Motion
>
> (905) 629-4746 x14369
>
> ________________________________________
> From: Filip Maj [fil@adobe.com]
> Sent: Tuesday, May 29, 2012 2:02 PM
> To: callback-dev@incubator.apache.org
> Subject: Re: Cordova and config.xml
>
> Just want to point out too that mozilla has/is working on their equivalent
> of config.xml
>
> https://developer.mozilla.org/en/Apps/Manifest
>
>
> JSON! :r
>
> On 5/29/12 10:57 AM, "Shazron" <shazron@gmail.com> wrote:
>
> >I concur - we had this discussion sometime ago but with respect to the
> >whitelist, and eventually decided to support access tags in config.xml to
> >consolidate all the platforms. We didn't have a plan then on when to
> >include this feature. Not seeing it in the Roadmap though pre-2.0 or even
> >for 2.0: http://wiki.apache.org/cordova/RoadmapProjects
> >
> >On Tue, May 29, 2012 at 9:49 AM, Michael Brooks
> ><michael@michaelbrooks.ca>wrote:
> >
> >> From my understanding, yes.
> >>
> >> PhoneGap Build currently uses it (not as extensively as BB) to describe
> >>the
> >> app's metadata and configuration (access, permissions, etc).
> >>
> >> My understanding is that as we build out the CLI for Apache Cordova,
> >>then
> >> config.xml support will be added.
> >>
> >> Michael
> >>
> >> On Mon, May 28, 2012 at 1:12 PM, Gord Tanner <gtanner@gmail.com> wrote:
> >>
> >> > Hey,
> >> >
> >> > I am wondering if cordova is going to continue aligning to the W3C
> >> > config.xml?
> >> >
> >> > Unless I am mistaken it looks like BlackBerry and PlayBook are the
> >>only
> >> > platforms that are currently using it.  Is there plans to use
> >>config.xml
> >> > more cross platform?
> >> >
> >>
>
>
> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by the
> solicitor-client or other applicable privileges), or constitute non-public
> information. Any use of this information by anyone other than the intended
> recipient is prohibited. If you have received this transmission in error,
> please immediately reply to the sender and delete this information from
> your system. Use, dissemination, distribution, or reproduction of this
> transmission by unintended recipients is not authorized and may be unlawful.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message