Re: amazon-fireos github mirror

[Brian LeRoux]

Hey Archana, you have to actually ping INFRA yourself. They have a mailing
list and irc. (Sometimes commenting on the issue helps.)


On Fri, Jan 3, 2014 at 6:30 PM, Naik, Archana  wrote:

> https://issues.apache.org/jira/browse/INFRA-7054
>
> No mirror yet. Can someone in INFRA please follow up?
>
> Thanks
> Archana
>

amazon-fireos github mirror

[Naik, Archana]

https://issues.apache.org/jira/browse/INFRA-7054

No mirror yet. Can someone in INFRA please follow up?

Thanks
Archana

Re: Default template - size

[Axel Nennker]

I think that my questions go away when www/config.xml moves to config.xml.
You have looked at the initial code and commented on it. Anything new on
the current code?
I will change the code tomorrow so that SRC becomes relatively to
project-dir and remove the re/icon logic.

Axel
On Jan 3, 2014 10:13 PM, "Andrew Grieve"  wrote:

> As long as they can specify the path to their icons, I think they can put
> them wherever they want.
>
> What input are you looking for?
>
>
> On Sat, Dec 21, 2013 at 4:14 PM, Axel Nennker 
> wrote:
>
> > I suggest to move the icons to /res/icons/ and
> copy
> > them from there to the platform www. Although this has several drawbacks:
> >
> > - testing the UI in a browser by opening www/index.html might surprise
> some
> > developers because they use the icons not only to represent the app but
> > also in the UI.
> > - Some might expect the icon to be relative to config.xml. " > src='icon.png' /> looks like icon.png is next to config.xml
> > - Sharing icons between platforms become irksome (soft links?)
> > - Maybe cordova should search in several places? www/icon.png and
> > res/icon/icon.png and res/icon//icon.png (in this order?)
> >
> > I started to work on CB-2606
> >
> >
> https://github.com/AxelNennker/cordova-cli/blob/master/src/metadata/android_parser.js#L75
> > but need input from this group how to implement this.
> >
> > -Axel
> >
> >
> >
> > 2013/10/22 Wargo, John 
> >
> > > I brought this up with fil a while back and it's a documented issue in
> > > jira.  He said config.xml had to be fixed to support different platform
> > > icons before something could be done about this.  I can dig up the
> email
> > > and forward it off tomorrow.
> > >
> > > John M. Wargo
> > >
> > > > On Oct 18, 2013, at 3:01 PM, "Steven Gill" 
> > > wrote:
> > > >
> > > > They should be in the merge folder under each platform instead of the
> > > www.
> > > >
> > > >
> > > >> On Fri, Oct 18, 2013 at 11:52 AM, Shazron 
> wrote:
> > > >>
> > > >> When someone creates a vanilla iOS project from the CLI, the default
> > > app is
> > > >> 8 MB. It's obvious why this is so, the www/res folder includes all
> the
> > > >> icons for all the platforms and is 8 MB.
> > > >>
> > > >> Can we change this (why include all icons -- the www should be
> > > agnostic),
> > > >> or is this a documentation problem.
> > > >>
> > >
> >
>

Re: storage

[Dick Van den Brink]

I use this shim and use it for iOS and android and after patching it works 
great!

The latest build is completely broken without patches, see my pull reqs on 
github and some others.

I'm all for using this as a starting point but it has been broken for almost 4 
months now without manually applying patches. (I'm talking about iterating over 
indexes and cursor.Update being broken). 

If we want to use this, we should never have such a situation again.



Verzonden met Windows Mail





Van: Parashuram Narasimhan (MS OPEN TECH)
Verzonden: ‎vrijdag‎ ‎3‎ ‎januari‎ ‎2014 ‎20‎:‎27
Aan: dev@cordova.apache.org





I gave IndexedDB shim over websql a shot, but it is not 100% compliant and has 
some bugs - http://github.com/axemclion/indexeddbshim. I am working on fixing 
the bugs, but to the level it works, I tested and it works with Cordova well !! 
Could we use that as a starting point ? 

-Original Message-
From: brian.ler...@gmail.com [mailto:brian.ler...@gmail.com] On Behalf Of Brian 
LeRoux
Sent: Friday, January 3, 2014 10:37 AM
To: dev@cordova.apache.org
Subject: Re: storage

an indexeddb plugin would be a rad thing for the community to create and 
maintain ;)

in seriousness: the file api is probably what you're really looking for if you 
want to read/write json on phones (you could even use it as a basis for an JS 
only plugin that polyfills indexeddb.


On Fri, Jan 3, 2014 at 5:30 AM, Axel Nennker  wrote:

> Hi,
>
> I was wondering about the cross-platform experience of Storage.
>
> http://cordova.apache.org/docs/en/3.3.0/cordova_storage_storage.md.htm
> l#Storage
>
> It seems that there is no cross platform solution in Cordova, right?
>
> There are indexeddb shims that implement indexeddb on "all" platforms.
> Shouldn't storage be indexeddb only? websql is deprecated.
>
> My team is currently facing the problem that we implemented a project 
> with Cordova's websql on Android and IOS but it is not supported on FirefoxOS.
> Now I wish we had started with indexeddb and used a shim on IOS. Argh.
>
> I think the text on cross platform storage in 
> cordova_storage_storage.mdis not really helping developers.
>
> Advice?
>
> Thanks
> Axel
>

Re: Default template - size

[Andrew Grieve]

As long as they can specify the path to their icons, I think they can put
them wherever they want.

What input are you looking for?


On Sat, Dec 21, 2013 at 4:14 PM, Axel Nennker  wrote:

> I suggest to move the icons to /res/icons/ and copy
> them from there to the platform www. Although this has several drawbacks:
>
> - testing the UI in a browser by opening www/index.html might surprise some
> developers because they use the icons not only to represent the app but
> also in the UI.
> - Some might expect the icon to be relative to config.xml. " src='icon.png' /> looks like icon.png is next to config.xml
> - Sharing icons between platforms become irksome (soft links?)
> - Maybe cordova should search in several places? www/icon.png and
> res/icon/icon.png and res/icon//icon.png (in this order?)
>
> I started to work on CB-2606
>
> https://github.com/AxelNennker/cordova-cli/blob/master/src/metadata/android_parser.js#L75
> but need input from this group how to implement this.
>
> -Axel
>
>
>
> 2013/10/22 Wargo, John 
>
> > I brought this up with fil a while back and it's a documented issue in
> > jira.  He said config.xml had to be fixed to support different platform
> > icons before something could be done about this.  I can dig up the email
> > and forward it off tomorrow.
> >
> > John M. Wargo
> >
> > > On Oct 18, 2013, at 3:01 PM, "Steven Gill" 
> > wrote:
> > >
> > > They should be in the merge folder under each platform instead of the
> > www.
> > >
> > >
> > >> On Fri, Oct 18, 2013 at 11:52 AM, Shazron  wrote:
> > >>
> > >> When someone creates a vanilla iOS project from the CLI, the default
> > app is
> > >> 8 MB. It's obvious why this is so, the www/res folder includes all the
> > >> icons for all the platforms and is 8 MB.
> > >>
> > >> Can we change this (why include all icons -- the www should be
> > agnostic),
> > >> or is this a documentation problem.
> > >>
> >
>

Re: template?

[Mark Koudritsky]

On Fri, Jan 3, 2014 at 3:01 PM, Wargo, John  wrote:

> +1. JSON on the command line is...more complicated than it should be.
>
> IMHO We still need a way to pass in a template folder. Is there a reason
> we're counting parameters rather than just exposing a tmpl=file_path
> parameter that could be used (or not used) as needed on the command line?
>
> The flag for custom template was added recently, but not yet part of the
latest official release, it looks like
--src=/path/to/custom/www_dir
or
--link=/path/to/custom/www_dir

here is the commit
https://github.com/apache/cordova-cli/commit/9b7fedf843f9ca5aef8e738e1349581666e2f716

RE: template?

[Wargo, John]

+1. JSON on the command line is...more complicated than it should be.

IMHO We still need a way to pass in a template folder. Is there a reason we're 
counting parameters rather than just exposing a tmpl=file_path parameter that 
could be used (or not used) as needed on the command line?

-Original Message-
From: Mark Koudritsky [mailto:kam...@google.com] 
Sent: Friday, January 03, 2014 11:51 AM
To: dev@cordova.apache.org
Subject: Re: template?

+1 for removing this JSON param. Passing JSON on command line is indeed
frightening.

The bit of internal api for passing another param with an object to
create() to initialize config.json file was added by me for the use of
mca.js

This indeed caused a crash when there was a 4th cli param because it was a
string and not an object with expected structure. To fix this I added a
line to JSON desalinize the param if was a string. But I believe this was a
mistake because adding JSON command line params is way to hackish. Instead
it should raise an error if there are more than 3 cli params to create.


On Fri, Jan 3, 2014 at 11:42 AM, Josh Soref  wrote:

> It's intended. It matches the internal api. Before the system resulted in
> a crash when you passed a fourth argument.  This way you can do whatever
> you want.
>
> I probably should have spoken up when the -- bits were added and asked why
> they were necessary. ‎
> -
> 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.
>

Re: Moving .cordova/config.json -> cordova.json

[Brian LeRoux]

probably a good idea for the moment / at some we will have a config file
reckoning!


On Fri, Jan 3, 2014 at 11:34 AM, Andrew Grieve  wrote:

> Okay, yeah, reading that back to myself and it seems like a bad idea
> (config.xml->app.xml). Probably would just add to confusion.
>
> So, top-level config.xml and top-level cordova.json.
>
> Maybe I could add to this that we don't create a cordova.json by default,
> since 99% most people shouldn't need it.
>
>
> On Fri, Jan 3, 2014 at 2:31 PM, Brian LeRoux  wrote:
>
> > actually, let me put this another way: I support .cordova/config.json ->
> > cordova.json but I am not really interested in changing the name of
> > ./www/config.xml to ./www/app.xml
> >
> > ...feels to me we could consolidate this entire sitation with a single
> well
> > crafted configuration file (at the top level). ideally we have more
> > convention than configuration. feels like we have too many footguns to
> ease
> > our personal dev workflows as is than consideration for people actually
> > building apps.
> >
> >
> > On Fri, Jan 3, 2014 at 11:25 AM, Brian LeRoux  wrote:
> >
> > > Sorry, I completely do not understand this at all. The proposal is to
> > > change the name of config.xml to ease confusions and add a new top
> level
> > > config file?
> > >
> > >
> > > On Fri, Jan 3, 2014 at 11:15 AM, Andrew Grieve  > >wrote:
> > >
> > >> Just spoke with Ian and I now understand his point about cordova.json
> > >> being
> > >> for build environment, whereas config.xml is for application things.
> > >>
> > >> So, do think it'd be bad to have a cordova.json and a config.xml right
> > >> next
> > >> to each other.
> > >>
> > >> How about:
> > >>
> > >> config.xml -> app.xml
> > >>  - This will (hopefully) ease confusion about CLI's config.xml vs.
> > >> platforms/ config.xml files.
> > >>  - E.g. we're adding icon & splashscreen support to CLI's config.xml,
> > but
> > >> not for non-CLI config.xml files
> > >>  - E.g. app.xml and plugin.xml is where you make edits, config.xml is
> > >> what's read at runtime.
> > >>
> > >> .cordova/config.json -> cordova.json
> > >>
> > >> Also - JIRA for this is https://issues.apache.org/jira/browse/CB-4910
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> On Thu, Jan 2, 2014 at 4:10 PM, Brian LeRoux  wrote:
> > >>
> > >> > I understood and read it too Gorkem.
> > >> >
> > >> > I was (poorly) suggesting we look at the issue of configuration in a
> > >> > complete view. Due to backwards compatibility we will be adding a
> new
> > >> file
> > >> > and the code to support the old file will be around a while.
> > >> >
> > >> > We can probably roll a whole lot more into a single file. What I"m
> not
> > >> sure
> > >> > about is what should and should not be.
> > >> >
> > >> >
> > >> > On Thu, Jan 2, 2014 at 12:31 PM, Gorkem Ercan <
> gorkem.er...@gmail.com
> > >> > >wrote:
> > >> >
> > >> > >
> > >> > > Reducing the number of configuration files is actually the goal
> > here.
> > >> > >
> > >> > > The abstraction is not a new one. It already exists and it is part
> > of
> > >> the
> > >> > > $PROJECT/.cordova/config.json.
> > >> > > I am suggesting to move it to $HOME/.cordova/config.json so that
> we
> > no
> > >> > > longer need the
> > >> > > $PROJECT/.cordova/config.json and have only the cordova.xml to
> carry
> > >> > > project specific
> > >> > > properties.
> > >> > > --
> > >> > > Gorkem
> > >> > >
> > >> > >
> > >> > > On Thu, Jan 02, 2014 at 12:16:57PM -0800, Brian LeRoux wrote:
> > >> > > > Considering http://wiki.apache.org/cordova/ConfigurationFilesI'm
> > >> not
> > >> > > sure
> > >> > > > we want more config either.
> > >> > > >
> > >> > > > Perhaps we need to think more comprehensively rather than
> > proposing
> > >> > more
> > >> > > > abstractions.
> > >> > > >
> > >> > > >
> > >> > > > On Thu, Jan 2, 2014 at 11:15 AM, Gorkem Ercan <
> > >> gorkem.er...@gmail.com
> > >> > > >wrote:
> > >> > > >
> > >> > > > >
> > >> > > > > I think what I will describe here is more that what CLI
> provides
> > >> > today.
> > >> > > > >
> > >> > > > > An engine/lib has a version, id and a uri. On most cases, you
> > only
> > >> > care
> > >> > > > > about the
> > >> > > > > id and uri and assume that the tools that you work with
> already
> > >> knows
> > >> > > how
> > >> > > > > to
> > >> > > > > resolve the id and version to a location. In the case of CLI
> an
> > >> > engine
> > >> > > > > with id: cordova
> > >> > > > > and version:3.1.0 should be resolved to
> > >> > > ~/.cordova/lib/ios/cordova/3.1.0 .
> > >> > > > > If we have a
> > >> > > > > uri defined that actually means we want to overwrite the
> default
> > >> > > location
> > >> > > > > for the engine.
> > >> > > > > I think this redirection should be per engine not per project
> > and
> > >> > > should
> > >> > > > > be located as part of
> > >> > > > > CLI's configuration
> > >> > > > > --
> > >> > > > > Gorkem
> > >> > > > >
> > >> > > > > On Thu, Jan 02, 2014 at 01:28:12PM -0500, Andrew Grieve wrote:
>

Re: Moving .cordova/config.json -> cordova.json

[Andrew Grieve]

Okay, yeah, reading that back to myself and it seems like a bad idea
(config.xml->app.xml). Probably would just add to confusion.

So, top-level config.xml and top-level cordova.json.

Maybe I could add to this that we don't create a cordova.json by default,
since 99% most people shouldn't need it.


On Fri, Jan 3, 2014 at 2:31 PM, Brian LeRoux  wrote:

> actually, let me put this another way: I support .cordova/config.json ->
> cordova.json but I am not really interested in changing the name of
> ./www/config.xml to ./www/app.xml
>
> ...feels to me we could consolidate this entire sitation with a single well
> crafted configuration file (at the top level). ideally we have more
> convention than configuration. feels like we have too many footguns to ease
> our personal dev workflows as is than consideration for people actually
> building apps.
>
>
> On Fri, Jan 3, 2014 at 11:25 AM, Brian LeRoux  wrote:
>
> > Sorry, I completely do not understand this at all. The proposal is to
> > change the name of config.xml to ease confusions and add a new top level
> > config file?
> >
> >
> > On Fri, Jan 3, 2014 at 11:15 AM, Andrew Grieve  >wrote:
> >
> >> Just spoke with Ian and I now understand his point about cordova.json
> >> being
> >> for build environment, whereas config.xml is for application things.
> >>
> >> So, do think it'd be bad to have a cordova.json and a config.xml right
> >> next
> >> to each other.
> >>
> >> How about:
> >>
> >> config.xml -> app.xml
> >>  - This will (hopefully) ease confusion about CLI's config.xml vs.
> >> platforms/ config.xml files.
> >>  - E.g. we're adding icon & splashscreen support to CLI's config.xml,
> but
> >> not for non-CLI config.xml files
> >>  - E.g. app.xml and plugin.xml is where you make edits, config.xml is
> >> what's read at runtime.
> >>
> >> .cordova/config.json -> cordova.json
> >>
> >> Also - JIRA for this is https://issues.apache.org/jira/browse/CB-4910
> >>
> >>
> >>
> >>
> >>
> >> On Thu, Jan 2, 2014 at 4:10 PM, Brian LeRoux  wrote:
> >>
> >> > I understood and read it too Gorkem.
> >> >
> >> > I was (poorly) suggesting we look at the issue of configuration in a
> >> > complete view. Due to backwards compatibility we will be adding a new
> >> file
> >> > and the code to support the old file will be around a while.
> >> >
> >> > We can probably roll a whole lot more into a single file. What I"m not
> >> sure
> >> > about is what should and should not be.
> >> >
> >> >
> >> > On Thu, Jan 2, 2014 at 12:31 PM, Gorkem Ercan  >> > >wrote:
> >> >
> >> > >
> >> > > Reducing the number of configuration files is actually the goal
> here.
> >> > >
> >> > > The abstraction is not a new one. It already exists and it is part
> of
> >> the
> >> > > $PROJECT/.cordova/config.json.
> >> > > I am suggesting to move it to $HOME/.cordova/config.json so that we
> no
> >> > > longer need the
> >> > > $PROJECT/.cordova/config.json and have only the cordova.xml to carry
> >> > > project specific
> >> > > properties.
> >> > > --
> >> > > Gorkem
> >> > >
> >> > >
> >> > > On Thu, Jan 02, 2014 at 12:16:57PM -0800, Brian LeRoux wrote:
> >> > > > Considering http://wiki.apache.org/cordova/ConfigurationFiles I'm
> >> not
> >> > > sure
> >> > > > we want more config either.
> >> > > >
> >> > > > Perhaps we need to think more comprehensively rather than
> proposing
> >> > more
> >> > > > abstractions.
> >> > > >
> >> > > >
> >> > > > On Thu, Jan 2, 2014 at 11:15 AM, Gorkem Ercan <
> >> gorkem.er...@gmail.com
> >> > > >wrote:
> >> > > >
> >> > > > >
> >> > > > > I think what I will describe here is more that what CLI provides
> >> > today.
> >> > > > >
> >> > > > > An engine/lib has a version, id and a uri. On most cases, you
> only
> >> > care
> >> > > > > about the
> >> > > > > id and uri and assume that the tools that you work with already
> >> knows
> >> > > how
> >> > > > > to
> >> > > > > resolve the id and version to a location. In the case of CLI an
> >> > engine
> >> > > > > with id: cordova
> >> > > > > and version:3.1.0 should be resolved to
> >> > > ~/.cordova/lib/ios/cordova/3.1.0 .
> >> > > > > If we have a
> >> > > > > uri defined that actually means we want to overwrite the default
> >> > > location
> >> > > > > for the engine.
> >> > > > > I think this redirection should be per engine not per project
> and
> >> > > should
> >> > > > > be located as part of
> >> > > > > CLI's configuration
> >> > > > > --
> >> > > > > Gorkem
> >> > > > >
> >> > > > > On Thu, Jan 02, 2014 at 01:28:12PM -0500, Andrew Grieve wrote:
> >> > > > > > Hmm, good point about absolute paths.
> >> > > > > >
> >> > > > > > I think if you're using an override there though, that you
> could
> >> > set
> >> > > it
> >> > > > > to
> >> > > > > > a relative path for shared projects. Same thing with plugin
> >> search
> >> > > paths.
> >> > > > > >
> >> > > > > > I think it'll be confusing to have a "cordova.xml" as well as
> a
> >> > > > > > "cordova.json" file right in the root.
> >> > > > > >
> >> > > >

Re: Moving .cordova/config.json -> cordova.json

[Brian LeRoux]

actually, let me put this another way: I support .cordova/config.json ->
cordova.json but I am not really interested in changing the name of
./www/config.xml to ./www/app.xml

...feels to me we could consolidate this entire sitation with a single well
crafted configuration file (at the top level). ideally we have more
convention than configuration. feels like we have too many footguns to ease
our personal dev workflows as is than consideration for people actually
building apps.


On Fri, Jan 3, 2014 at 11:25 AM, Brian LeRoux  wrote:

> Sorry, I completely do not understand this at all. The proposal is to
> change the name of config.xml to ease confusions and add a new top level
> config file?
>
>
> On Fri, Jan 3, 2014 at 11:15 AM, Andrew Grieve wrote:
>
>> Just spoke with Ian and I now understand his point about cordova.json
>> being
>> for build environment, whereas config.xml is for application things.
>>
>> So, do think it'd be bad to have a cordova.json and a config.xml right
>> next
>> to each other.
>>
>> How about:
>>
>> config.xml -> app.xml
>>  - This will (hopefully) ease confusion about CLI's config.xml vs.
>> platforms/ config.xml files.
>>  - E.g. we're adding icon & splashscreen support to CLI's config.xml, but
>> not for non-CLI config.xml files
>>  - E.g. app.xml and plugin.xml is where you make edits, config.xml is
>> what's read at runtime.
>>
>> .cordova/config.json -> cordova.json
>>
>> Also - JIRA for this is https://issues.apache.org/jira/browse/CB-4910
>>
>>
>>
>>
>>
>> On Thu, Jan 2, 2014 at 4:10 PM, Brian LeRoux  wrote:
>>
>> > I understood and read it too Gorkem.
>> >
>> > I was (poorly) suggesting we look at the issue of configuration in a
>> > complete view. Due to backwards compatibility we will be adding a new
>> file
>> > and the code to support the old file will be around a while.
>> >
>> > We can probably roll a whole lot more into a single file. What I"m not
>> sure
>> > about is what should and should not be.
>> >
>> >
>> > On Thu, Jan 2, 2014 at 12:31 PM, Gorkem Ercan > > >wrote:
>> >
>> > >
>> > > Reducing the number of configuration files is actually the goal here.
>> > >
>> > > The abstraction is not a new one. It already exists and it is part of
>> the
>> > > $PROJECT/.cordova/config.json.
>> > > I am suggesting to move it to $HOME/.cordova/config.json so that we no
>> > > longer need the
>> > > $PROJECT/.cordova/config.json and have only the cordova.xml to carry
>> > > project specific
>> > > properties.
>> > > --
>> > > Gorkem
>> > >
>> > >
>> > > On Thu, Jan 02, 2014 at 12:16:57PM -0800, Brian LeRoux wrote:
>> > > > Considering http://wiki.apache.org/cordova/ConfigurationFiles I'm
>> not
>> > > sure
>> > > > we want more config either.
>> > > >
>> > > > Perhaps we need to think more comprehensively rather than proposing
>> > more
>> > > > abstractions.
>> > > >
>> > > >
>> > > > On Thu, Jan 2, 2014 at 11:15 AM, Gorkem Ercan <
>> gorkem.er...@gmail.com
>> > > >wrote:
>> > > >
>> > > > >
>> > > > > I think what I will describe here is more that what CLI provides
>> > today.
>> > > > >
>> > > > > An engine/lib has a version, id and a uri. On most cases, you only
>> > care
>> > > > > about the
>> > > > > id and uri and assume that the tools that you work with already
>> knows
>> > > how
>> > > > > to
>> > > > > resolve the id and version to a location. In the case of CLI an
>> > engine
>> > > > > with id: cordova
>> > > > > and version:3.1.0 should be resolved to
>> > > ~/.cordova/lib/ios/cordova/3.1.0 .
>> > > > > If we have a
>> > > > > uri defined that actually means we want to overwrite the default
>> > > location
>> > > > > for the engine.
>> > > > > I think this redirection should be per engine not per project and
>> > > should
>> > > > > be located as part of
>> > > > > CLI's configuration
>> > > > > --
>> > > > > Gorkem
>> > > > >
>> > > > > On Thu, Jan 02, 2014 at 01:28:12PM -0500, Andrew Grieve wrote:
>> > > > > > Hmm, good point about absolute paths.
>> > > > > >
>> > > > > > I think if you're using an override there though, that you could
>> > set
>> > > it
>> > > > > to
>> > > > > > a relative path for shared projects. Same thing with plugin
>> search
>> > > paths.
>> > > > > >
>> > > > > > I think it'll be confusing to have a "cordova.xml" as well as a
>> > > > > > "cordova.json" file right in the root.
>> > > > > >
>> > > > > > WDYT? Other options?
>> > > > > >
>> > > > > >
>> > > > > > On Thu, Jan 2, 2014 at 1:06 PM, Ian Clelland <
>> > iclell...@chromium.org
>> > > >
>> > > > > wrote:
>> > > > > >
>> > > > > > > On Thu, Jan 2, 2014 at 10:22 AM, Andrew Grieve <
>> > > agri...@chromium.org>
>> > > > > > > wrote:
>> > > > > > >
>> > > > > > > > What cordova.json has that config.xml doesn't, is that you
>> can
>> > > set
>> > > > > the
>> > > > > > > > location of platforms with it through:
>> > > > > > > >
>> > > > > > > >
>> > > > > > >
>> > > > > > > >
>> > > > > > > > That said, I like your idea of having one top-level config
>> file
>> > > > > instea

RE: storage

[Parashuram Narasimhan (MS OPEN TECH)]

I gave IndexedDB shim over websql a shot, but it is not 100% compliant and has 
some bugs - http://github.com/axemclion/indexeddbshim. I am working on fixing 
the bugs, but to the level it works, I tested and it works with Cordova well !! 
Could we use that as a starting point ? 

-Original Message-
From: brian.ler...@gmail.com [mailto:brian.ler...@gmail.com] On Behalf Of Brian 
LeRoux
Sent: Friday, January 3, 2014 10:37 AM
To: dev@cordova.apache.org
Subject: Re: storage

an indexeddb plugin would be a rad thing for the community to create and 
maintain ;)

in seriousness: the file api is probably what you're really looking for if you 
want to read/write json on phones (you could even use it as a basis for an JS 
only plugin that polyfills indexeddb.


On Fri, Jan 3, 2014 at 5:30 AM, Axel Nennker  wrote:

> Hi,
>
> I was wondering about the cross-platform experience of Storage.
>
> http://cordova.apache.org/docs/en/3.3.0/cordova_storage_storage.md.htm
> l#Storage
>
> It seems that there is no cross platform solution in Cordova, right?
>
> There are indexeddb shims that implement indexeddb on "all" platforms.
> Shouldn't storage be indexeddb only? websql is deprecated.
>
> My team is currently facing the problem that we implemented a project 
> with Cordova's websql on Android and IOS but it is not supported on FirefoxOS.
> Now I wish we had started with indexeddb and used a shim on IOS. Argh.
>
> I think the text on cross platform storage in 
> cordova_storage_storage.mdis not really helping developers.
>
> Advice?
>
> Thanks
> Axel
>

Re: Moving .cordova/config.json -> cordova.json

[Brian LeRoux]

Sorry, I completely do not understand this at all. The proposal is to
change the name of config.xml to ease confusions and add a new top level
config file?


On Fri, Jan 3, 2014 at 11:15 AM, Andrew Grieve  wrote:

> Just spoke with Ian and I now understand his point about cordova.json being
> for build environment, whereas config.xml is for application things.
>
> So, do think it'd be bad to have a cordova.json and a config.xml right next
> to each other.
>
> How about:
>
> config.xml -> app.xml
>  - This will (hopefully) ease confusion about CLI's config.xml vs.
> platforms/ config.xml files.
>  - E.g. we're adding icon & splashscreen support to CLI's config.xml, but
> not for non-CLI config.xml files
>  - E.g. app.xml and plugin.xml is where you make edits, config.xml is
> what's read at runtime.
>
> .cordova/config.json -> cordova.json
>
> Also - JIRA for this is https://issues.apache.org/jira/browse/CB-4910
>
>
>
>
>
> On Thu, Jan 2, 2014 at 4:10 PM, Brian LeRoux  wrote:
>
> > I understood and read it too Gorkem.
> >
> > I was (poorly) suggesting we look at the issue of configuration in a
> > complete view. Due to backwards compatibility we will be adding a new
> file
> > and the code to support the old file will be around a while.
> >
> > We can probably roll a whole lot more into a single file. What I"m not
> sure
> > about is what should and should not be.
> >
> >
> > On Thu, Jan 2, 2014 at 12:31 PM, Gorkem Ercan  > >wrote:
> >
> > >
> > > Reducing the number of configuration files is actually the goal here.
> > >
> > > The abstraction is not a new one. It already exists and it is part of
> the
> > > $PROJECT/.cordova/config.json.
> > > I am suggesting to move it to $HOME/.cordova/config.json so that we no
> > > longer need the
> > > $PROJECT/.cordova/config.json and have only the cordova.xml to carry
> > > project specific
> > > properties.
> > > --
> > > Gorkem
> > >
> > >
> > > On Thu, Jan 02, 2014 at 12:16:57PM -0800, Brian LeRoux wrote:
> > > > Considering http://wiki.apache.org/cordova/ConfigurationFiles I'm
> not
> > > sure
> > > > we want more config either.
> > > >
> > > > Perhaps we need to think more comprehensively rather than proposing
> > more
> > > > abstractions.
> > > >
> > > >
> > > > On Thu, Jan 2, 2014 at 11:15 AM, Gorkem Ercan <
> gorkem.er...@gmail.com
> > > >wrote:
> > > >
> > > > >
> > > > > I think what I will describe here is more that what CLI provides
> > today.
> > > > >
> > > > > An engine/lib has a version, id and a uri. On most cases, you only
> > care
> > > > > about the
> > > > > id and uri and assume that the tools that you work with already
> knows
> > > how
> > > > > to
> > > > > resolve the id and version to a location. In the case of CLI an
> > engine
> > > > > with id: cordova
> > > > > and version:3.1.0 should be resolved to
> > > ~/.cordova/lib/ios/cordova/3.1.0 .
> > > > > If we have a
> > > > > uri defined that actually means we want to overwrite the default
> > > location
> > > > > for the engine.
> > > > > I think this redirection should be per engine not per project and
> > > should
> > > > > be located as part of
> > > > > CLI's configuration
> > > > > --
> > > > > Gorkem
> > > > >
> > > > > On Thu, Jan 02, 2014 at 01:28:12PM -0500, Andrew Grieve wrote:
> > > > > > Hmm, good point about absolute paths.
> > > > > >
> > > > > > I think if you're using an override there though, that you could
> > set
> > > it
> > > > > to
> > > > > > a relative path for shared projects. Same thing with plugin
> search
> > > paths.
> > > > > >
> > > > > > I think it'll be confusing to have a "cordova.xml" as well as a
> > > > > > "cordova.json" file right in the root.
> > > > > >
> > > > > > WDYT? Other options?
> > > > > >
> > > > > >
> > > > > > On Thu, Jan 2, 2014 at 1:06 PM, Ian Clelland <
> > iclell...@chromium.org
> > > >
> > > > > wrote:
> > > > > >
> > > > > > > On Thu, Jan 2, 2014 at 10:22 AM, Andrew Grieve <
> > > agri...@chromium.org>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > What cordova.json has that config.xml doesn't, is that you
> can
> > > set
> > > > > the
> > > > > > > > location of platforms with it through:
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > That said, I like your idea of having one top-level config
> file
> > > > > instead
> > > > > > > of
> > > > > > > > two. I don't see why we couldn't just put these same settings
> > > into a
> > > > > > > > "cordova.xml".
> > > > > > > >
> > > > > > >
> > > > > > > Wouldn't this make it impossible to share project configuration
> > > between
> > > > > > > developers? If your /Users/agrieve/.../ paths are in your
> config
> > > xml,
> > > > > > > you're going to have a bad time putting that in version
> control.
> > > > > > >
> > > > > > > -1 on having a single file to manage both application config
> and
> > > > > > > build-environment config.
> > > > > > >
> > > > > > > +1 to the way I read Gorkem's original suggestion, which was to
> > > > > coordinate
> > > > 

Re: Moving .cordova/config.json -> cordova.json

[Andrew Grieve]

Just spoke with Ian and I now understand his point about cordova.json being
for build environment, whereas config.xml is for application things.

So, do think it'd be bad to have a cordova.json and a config.xml right next
to each other.

How about:

config.xml -> app.xml
 - This will (hopefully) ease confusion about CLI's config.xml vs.
platforms/ config.xml files.
 - E.g. we're adding icon & splashscreen support to CLI's config.xml, but
not for non-CLI config.xml files
 - E.g. app.xml and plugin.xml is where you make edits, config.xml is
what's read at runtime.

.cordova/config.json -> cordova.json

Also - JIRA for this is https://issues.apache.org/jira/browse/CB-4910





On Thu, Jan 2, 2014 at 4:10 PM, Brian LeRoux  wrote:

> I understood and read it too Gorkem.
>
> I was (poorly) suggesting we look at the issue of configuration in a
> complete view. Due to backwards compatibility we will be adding a new file
> and the code to support the old file will be around a while.
>
> We can probably roll a whole lot more into a single file. What I"m not sure
> about is what should and should not be.
>
>
> On Thu, Jan 2, 2014 at 12:31 PM, Gorkem Ercan  >wrote:
>
> >
> > Reducing the number of configuration files is actually the goal here.
> >
> > The abstraction is not a new one. It already exists and it is part of the
> > $PROJECT/.cordova/config.json.
> > I am suggesting to move it to $HOME/.cordova/config.json so that we no
> > longer need the
> > $PROJECT/.cordova/config.json and have only the cordova.xml to carry
> > project specific
> > properties.
> > --
> > Gorkem
> >
> >
> > On Thu, Jan 02, 2014 at 12:16:57PM -0800, Brian LeRoux wrote:
> > > Considering http://wiki.apache.org/cordova/ConfigurationFiles I'm not
> > sure
> > > we want more config either.
> > >
> > > Perhaps we need to think more comprehensively rather than proposing
> more
> > > abstractions.
> > >
> > >
> > > On Thu, Jan 2, 2014 at 11:15 AM, Gorkem Ercan  > >wrote:
> > >
> > > >
> > > > I think what I will describe here is more that what CLI provides
> today.
> > > >
> > > > An engine/lib has a version, id and a uri. On most cases, you only
> care
> > > > about the
> > > > id and uri and assume that the tools that you work with already knows
> > how
> > > > to
> > > > resolve the id and version to a location. In the case of CLI an
> engine
> > > > with id: cordova
> > > > and version:3.1.0 should be resolved to
> > ~/.cordova/lib/ios/cordova/3.1.0 .
> > > > If we have a
> > > > uri defined that actually means we want to overwrite the default
> > location
> > > > for the engine.
> > > > I think this redirection should be per engine not per project and
> > should
> > > > be located as part of
> > > > CLI's configuration
> > > > --
> > > > Gorkem
> > > >
> > > > On Thu, Jan 02, 2014 at 01:28:12PM -0500, Andrew Grieve wrote:
> > > > > Hmm, good point about absolute paths.
> > > > >
> > > > > I think if you're using an override there though, that you could
> set
> > it
> > > > to
> > > > > a relative path for shared projects. Same thing with plugin search
> > paths.
> > > > >
> > > > > I think it'll be confusing to have a "cordova.xml" as well as a
> > > > > "cordova.json" file right in the root.
> > > > >
> > > > > WDYT? Other options?
> > > > >
> > > > >
> > > > > On Thu, Jan 2, 2014 at 1:06 PM, Ian Clelland <
> iclell...@chromium.org
> > >
> > > > wrote:
> > > > >
> > > > > > On Thu, Jan 2, 2014 at 10:22 AM, Andrew Grieve <
> > agri...@chromium.org>
> > > > > > wrote:
> > > > > >
> > > > > > > What cordova.json has that config.xml doesn't, is that you can
> > set
> > > > the
> > > > > > > location of platforms with it through:
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > >
> > > > > > > That said, I like your idea of having one top-level config file
> > > > instead
> > > > > > of
> > > > > > > two. I don't see why we couldn't just put these same settings
> > into a
> > > > > > > "cordova.xml".
> > > > > > >
> > > > > >
> > > > > > Wouldn't this make it impossible to share project configuration
> > between
> > > > > > developers? If your /Users/agrieve/.../ paths are in your config
> > xml,
> > > > > > you're going to have a bad time putting that in version control.
> > > > > >
> > > > > > -1 on having a single file to manage both application config and
> > > > > > build-environment config.
> > > > > >
> > > > > > +1 to the way I read Gorkem's original suggestion, which was to
> > > > coordinate
> > > > > > the move of the two files into a single issue and take care of it
> > all
> > > > at
> > > > > > once.
> > > > > >
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Wed, Jan 1, 2014 at 5:05 PM, Gorkem Ercan <
> > gorkem.er...@gmail.com
> > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > There is also another proposal to move config.xml out of www.
> > Can
> > > > we
> > > > > > > merge
> > > > > > > > this two moves and
> > > > > > > > 1. remove .cordova
> > > > > > > > 2. remove config.json
> > > > > > > > 3. move 

Re: Moving www/config.xml -> config.xml (within CLI)

[Andrew Grieve]

Looks like there's already a JIRA for this:

https://issues.apache.org/jira/browse/CB-4910



On Thu, Jan 2, 2014 at 10:35 AM, Andrew Grieve  wrote:

> I'll make a JIRA issue on Tuesday and paste the link to it here.
>
>
> On Thu, Jan 2, 2014 at 10:32 AM, Ross Gerbasi  wrote:
>
>> Did this make it to jira? I also think its a good idea to pull config.xml
>> out of the www root. Anyway to track this one?
>>
>>
>> On Mon, Dec 30, 2013 at 1:51 PM, Dick Van den Brink <
>> d_vandenbr...@outlook.com> wrote:
>>
>> > I think it is a a good idea! So a +1
>> >
>> > Sent from my Windows Phone
>> > 
>> > From: Axel Nennker
>> > Sent: 12/30/2013 20:47
>> > To: dev
>> > Subject: Re: Moving www/config.xml -> config.xml (within CLI)
>> >
>> > I support this proposal.
>> >
>> > When I started work on CB-2606
>> > https://issues.apache.org/jira/browse/CB-2606I noticed that the
>> > element 
>> > suggests that icons are put next to config.xml as well.
>> > When config.xml is in the project root it becomes more natural to put
>> icons
>> > in /res/icons//icon.png
>> >
>> > -Axel
>> >
>> > ps:
>> > I need opinions on my current implementation of CB-2606.
>> > https://github.com/AxelNennker/cordova-cli
>> > Please chime in to the email thread with the subject "Started
>> Implementing
>> > CB-2606 Add support for > >
>> >
>> >
>> > 2013/12/30 Andrew Grieve 
>> >
>> > > I thought this was previously discussed, but I can't find any JIRA
>> issues
>> > > or old emails about it.
>> > >
>> > > Proposal:
>> > > For CLI projects:
>> > > - Use www/config.xml if it exists
>> > > - Otherwise use ./config.xml
>> > > - Change the project template to use ./config.xml by default
>> > >
>> > >
>> > > Reasons:
>> > > - Paths in config.xml are relative to project root
>> > > - Prevents a copy of config.xml ended up in platforms/*/www
>> > > - Manifests are generally found at the top-level of projects.
>> > >
>> > >
>> > > Sound good? If so I'll make an issue and work on this. Since it's
>> > holidays,
>> > > will wait until next week Tuesday (Jan 7) to proceed.
>> > >
>> > > Andrew
>> > >
>> >
>>
>
>

Re: storage

[Lucas Holmquist]

you should checkout the Datamanager stuff that we've been working on, on the 
aerogear project https://github.com/aerogear/aerogear-js#datamanager

It is designed to fallback to whatever is available on your platform

On Jan 3, 2014, at 8:30 AM, Axel Nennker  wrote:

> Hi,
> 
> I was wondering about the cross-platform experience of Storage.
> http://cordova.apache.org/docs/en/3.3.0/cordova_storage_storage.md.html#Storage
> 
> It seems that there is no cross platform solution in Cordova, right?
> 
> There are indexeddb shims that implement indexeddb on "all" platforms.
> Shouldn't storage be indexeddb only? websql is deprecated.
> 
> My team is currently facing the problem that we implemented a project with
> Cordova's websql on Android and IOS but it is not supported on FirefoxOS.
> Now I wish we had started with indexeddb and used a shim on IOS. Argh.
> 
> I think the text on cross platform storage in cordova_storage_storage.md is
> not really helping developers.
> 
> Advice?
> 
> Thanks
> Axel

Re: template?

[Brian LeRoux]

I'm all for this feature (and docs) but lets make it first class. Passing
the internal JSON representation feels like a leaky abstraction. The CLI
user should not know nor care about those internals and it would seem error
prone.


On Fri, Jan 3, 2014 at 9:24 AM, Mark Koudritsky  wrote:

> > Well. I'm the one who "Fixed" this.
> >
> My bad, it's indeed Josh's
> change<
> https://github.com/kamrik/cordova-cli/commit/6490967289e5116b69ef33f1c0a81facdb92ac18
> >,
> sorry for getting confused about this, this was discussed at the time for a
> bit and I thought about doing the same but Josh did it before and also
> added the doc text to CLI help.
>
> Still, I think the better thing to do in this case is not to expose the 4th
> param of create() function to the CLI and leave it for internal (API) use
> only. This is similar to how some of the other cordova command fucntions
> take the "options" parameter that is created from the command line with
> some logic or by upstream tools that use the api. It would be nice to
> actually rename it to "options" for consistency.
>

Re: storage

[Brian LeRoux]

an indexeddb plugin would be a rad thing for the community to create and
maintain ;)

in seriousness: the file api is probably what you're really looking for if
you want to read/write json on phones (you could even use it as a basis for
an JS only plugin that polyfills indexeddb.


On Fri, Jan 3, 2014 at 5:30 AM, Axel Nennker  wrote:

> Hi,
>
> I was wondering about the cross-platform experience of Storage.
>
> http://cordova.apache.org/docs/en/3.3.0/cordova_storage_storage.md.html#Storage
>
> It seems that there is no cross platform solution in Cordova, right?
>
> There are indexeddb shims that implement indexeddb on "all" platforms.
> Shouldn't storage be indexeddb only? websql is deprecated.
>
> My team is currently facing the problem that we implemented a project with
> Cordova's websql on Android and IOS but it is not supported on FirefoxOS.
> Now I wish we had started with indexeddb and used a shim on IOS. Argh.
>
> I think the text on cross platform storage in cordova_storage_storage.mdis
> not really helping developers.
>
> Advice?
>
> Thanks
> Axel
>

Re: template?

[Mark Koudritsky]

> Well. I'm the one who "Fixed" this.
>
My bad, it's indeed Josh's
change,
sorry for getting confused about this, this was discussed at the time for a
bit and I thought about doing the same but Josh did it before and also
added the doc text to CLI help.

Still, I think the better thing to do in this case is not to expose the 4th
param of create() function to the CLI and leave it for internal (API) use
only. This is similar to how some of the other cordova command fucntions
take the "options" parameter that is created from the command line with
some logic or by upstream tools that use the api. It would be nice to
actually rename it to "options" for consistency.

Re: template?

[Josh Soref]

Well. I'm the one who "Fixed" this. 

I'm obviously -1 on removing it without some more useful outcomes.

Just backing things out without fixing underlying flaws is a waste of energy. 
Should I have backed out your glue because you broke the command line? Surely 
that's ridiculous.  

It's really upsetting to find dozens of surprise command line behaviors which 
are not at all documented. 

** If you add an api you should ensure that you haven't changed the shape of 
the command line - as you did here.
** if you add an api to the command line, you should update the help 
** if you change the arguments accepted by the command line, you should change 
the help 
** you should not complain about people cleaning up after the mess that you make

‎I understand that people don't like that the JSON isn't particularly 
documented. I don't like it either, but everyone in the core group seems to 
enjoy spitting out random JSON to be added to the Cordova JSON file.

** The JSON file needs to be documented with or without this command line flag. 
-
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.

Re: template?

[Josh Soref]

Mark wrote:
> Is there an ETA for it?

Cordova works on a Cadence release cycle. It'll be in the next release which 
should be soon enough. 

> Can you say where the valid keys are documented?

I'm not sure there is a definitive list, it's basically anything that can end 
up in the project JSON. 

> You definitely see this argument documented when you type ³cordova²,

This is a lot better than most things where people add something and fail to 
document the option at all. 

> but nowhere do you see a list of what can be specified here.

This is a general problem with Cordova, we need a Cookbook showing examples of 
various things. You can for instance define where to get platforms from for 
`cordova platform add PLATFORM ` by including some similar content in the JSON. 

> It may be too long for the CLI docs, but
where can users find it online?

It's definitely too long for "help". 
‎
The best I've seen are random discussions on the mailing list (in response to 
"I can't do X"). 

At least initially, some could be in the Wiki. It should be in the docs just as 
the .xml file is documented.
-
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.

Re: template?

[Mark Koudritsky]

+1 for removing this JSON param. Passing JSON on command line is indeed
frightening.

The bit of internal api for passing another param with an object to
create() to initialize config.json file was added by me for the use of
mca.js

This indeed caused a crash when there was a 4th cli param because it was a
string and not an object with expected structure. To fix this I added a
line to JSON desalinize the param if was a string. But I believe this was a
mistake because adding JSON command line params is way to hackish. Instead
it should raise an error if there are more than 3 cli params to create.


On Fri, Jan 3, 2014 at 11:42 AM, Josh Soref  wrote:

> It's intended. It matches the internal api. Before the system resulted in
> a crash when you passed a fourth argument.  This way you can do whatever
> you want.
>
> I probably should have spoken up when the -- bits were added and asked why
> they were necessary. ‎
> -
> 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.
>

Re: template?

[Josh Soref]

It's intended. It matches the internal api. Before the system resulted in a 
crash when you passed a fourth argument.  This way you can do whatever you 
want. 

I probably should have spoken up when the -- bits were added and asked why they 
were necessary. ‎
-
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.

Re: template?

[Ray Camden]

On 1/3/14, 10:27 AM, "Mark Koudritsky"  wrote:

>The option to specify a template was added here, via --src or --link
>command line args.
>https://git-wip-us.apache.org/repos/asf?p=cordova-cli.git;h=9b7fedf
>
>But it's not yet part of any released version.

Is there an ETA for it?

>
>Passing a JSON string as the 4th param to CLI does seem to work, even
>though originally it was an artifact of a change done for a completely
>different purpose.
>
>The JSON string should look like:
>"lib":{"www":{"uri":"/path/to/custom_www"}}


Can you say where the valid keys are documented? You definitely see this
argument documented when you type ³cordova², but nowhere do you see a list
of what can be specified here. It may be too long for the CLI docs, but
where can users find it online?

Re: template?

[Andrew Grieve]

If adding the 4th param wasn't intentional, should we remove it? Passing a
JSON string via command line seems crazy.


On Fri, Jan 3, 2014 at 11:27 AM, Mark Koudritsky  wrote:

> The option to specify a template was added here, via --src or --link
> command line args.
> https://git-wip-us.apache.org/repos/asf?p=cordova-cli.git;h=9b7fedf
>
> But it's not yet part of any released version.
>
> Passing a JSON string as the 4th param to CLI does seem to work, even
> though originally it was an artifact of a change done for a completely
> different purpose.
>
> The JSON string should look like:
> "lib":{"www":{"uri":"/path/to/custom_www"}}
>
>
>
> On Fri, Jan 3, 2014 at 11:24 AM, Josh Soref  wrote:
>
> > There's a difference between the cli and the platform bin scripts.
> >
> > The platform bin scripts take a template directory or something. The cli
> > takes JSON which can include a template directory.
> >
> > Yes. It's confusing. But it does work. ‎
> > -
> > 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.
> >
>

Re: template?

[John M. Wargo]

sorry, not JSON file, but JSON string.

On 1/3/2014 11:16 AM, John Wargo wrote:

I thought I saw a thread a while back that said you'd be able to pass the CLI 
create command a path to a project folder that contains the web application 
template to use for the new project. I just installed 3.3 and according to the 
help, the 4th parameter points to a JSON file that contains key/value pairs 
that will be added to the project's config.json file.  Did I miss something?  I 
thought the team had added a way for developers to specify the web application 
project that would be used.

Re: template?

[Mark Koudritsky]

The option to specify a template was added here, via --src or --link
command line args.
https://git-wip-us.apache.org/repos/asf?p=cordova-cli.git;h=9b7fedf

But it's not yet part of any released version.

Passing a JSON string as the 4th param to CLI does seem to work, even
though originally it was an artifact of a change done for a completely
different purpose.

The JSON string should look like:
"lib":{"www":{"uri":"/path/to/custom_www"}}



On Fri, Jan 3, 2014 at 11:24 AM, Josh Soref  wrote:

> There's a difference between the cli and the platform bin scripts.
>
> The platform bin scripts take a template directory or something. The cli
> takes JSON which can include a template directory.
>
> Yes. It's confusing. But it does work. ‎
> -
> 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.
>

Re: template?

[Josh Soref]

There's a difference between the cli and the platform bin scripts. 

The platform bin scripts take a template directory or something. The cli takes 
JSON which can include a template directory. 

Yes. It's confusing. But it does work. ‎
-
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.

template?

[John Wargo]

I thought I saw a thread a while back that said you'd be able to pass the CLI 
create command a path to a project folder that contains the web application 
template to use for the new project. I just installed 3.3 and according to the 
help, the 4th parameter points to a JSON file that contains key/value pairs 
that will be added to the project's config.json file.  Did I miss something?  I 
thought the team had added a way for developers to specify the web application 
project that would be used.

storage

[Axel Nennker]

Hi,

I was wondering about the cross-platform experience of Storage.
http://cordova.apache.org/docs/en/3.3.0/cordova_storage_storage.md.html#Storage

It seems that there is no cross platform solution in Cordova, right?

There are indexeddb shims that implement indexeddb on "all" platforms.
Shouldn't storage be indexeddb only? websql is deprecated.

My team is currently facing the problem that we implemented a project with
Cordova's websql on Android and IOS but it is not supported on FirefoxOS.
Now I wish we had started with indexeddb and used a shim on IOS. Argh.

I think the text on cross platform storage in cordova_storage_storage.md is
not really helping developers.

Advice?

Thanks
Axel

Re: Add resource-file element to plugin.xml

[Axel Nennker]

Although source-file could be used I think it is wrong to use source-file
to copy files to  or it's subdirectory.
It just happens to work because on Android because the Android build system
just compiles every file in /src and uses every file in
/res to generate e.g gen/R.java
On other platforms (ios) the plugin author can even specify compiler flags.
source-file should only be used for files that are input to the compiler I
think.

Too bad that the documentation for resource file
http://cordova.apache.org/docs/en/3.3.0/plugin_ref_spec.md.html#Plugin%20Specification_resource_file_and_header_file_elements
does not specify a target. I think it should.

Every Android developer thinks that "resource-file" is intended to handle
file in e.g. /res/xml/
I think it is bad that the cordova leaves it to the developer to discover
that some elements (like lib-file or resource-file) do not work on their
target platform.

I think that resource-file should be implemented for Android and that there
should be a clear warning when it is not implemented on a platform like
e.g. firefoxos.

Could you please pull - at least - this?: (android.js)
https://github.com/AxelNennker/cordova-plugman/commit/97974f77859d78437d84086d2b927036359d971e

-Axel





2014/1/2 Axel Nennker 

> ios does something more than just copy files.
> ubuntu copies the src to a subdirectory named qml.
>
> source-file could be used on Android for my purposes. The major difference
> is that my implementation of resouce-file uses a target file instead of
> target-dir which would allow to rename the src.
>
> I suggest to improve the documentation to say that source-file could be
> used to move arbitrary files.
>
> -Axel
>
> ps: some implentations use common.copyFile while others use shell.cp to
> copy files. Is there a difference when copying binary files.
> What about --variable on binary files?
>
>
>
> 2014/1/2 Andrew Grieve 
>
>> I thought about  as well, but given that  is
>> already implemented on other platforms, I think it would make sense to
>> have
>> it for Android.
>>
>> Another thought is that it's more semantically correct.
>> E.g. We might at some point make target-dir optional for android (it's
>> optional on other platforms), and just infer the directory from the
>> package
>> declaration.
>>
>>
>> On Thu, Jan 2, 2014 at 1:47 PM, Joe Bowser  wrote:
>>
>> > Why is this needed?  You can use source file to copy resources.  This
>> > just adds XML for the sake of adding more XML.
>> >
>> > On Thu, Jan 2, 2014 at 10:36 AM, Andrew Grieve 
>> > wrote:
>> > > Looking at the plugin spec:
>> > >
>> >
>> http://cordova.apache.org/docs/en/3.3.0/plugin_ref_spec.md.html#Plugin%20Specification
>> > >
>> > > I think this sounds great! Certainly the section in there could use
>> some
>> > > elaboration, but I think I'd expect the tag to work as you've
>> implemented
>> > > it.
>> > >
>> > > If no one objects, I'll pull it in tomorrow.
>> > >
>> > >
>> > > On Thu, Jan 2, 2014 at 1:10 PM, Axel Nennker 
>> > wrote:
>> > >
>> > >> Hi,
>> > >>
>> > >> I created an issue in JIRA:
>> > >> https://issues.apache.org/jira/browse/CB-5720
>> > >>
>> > >> Description
>> > >>
>> > >> Add support for > > /> to
>> > >> a plugin's plugin.xml
>> > >>
>> > >> The above example would copy the file glass.xml from the plugin's
>> > directory
>> > >> to the platforms/android/res/xml/glass.xml
>> > >>
>> > >> The ubuntu platform had this feature already. Although undocumented.
>> > >>
>> > >> This is for the use case when a plugin in needs additional file e.g.
>> in
>> > >> res/xml or other directories.
>> > >> An example for Android would be an authenticator that is specified in
>> > >> AndroidManifest.xml
>> > >> The code to implement this is here
>> > >> https://github.com/AxelNennker/cordova-plugman
>> > >>
>> > >> The pull request is here:
>> > >> https://github.com/apache/cordova-plugman/pull/41
>> > >>
>> > >> -Axel
>> > >>
>> >
>>
>
>