cordova.io domain name
Hi all, The domain renewal for cordova.io is due in March 2013. How do other Apache projects manage custom domains? I've searched around apache.org without much luck. During our incubation period, there was a brief discussion about the domain name, but little progress was made. For myself, there are two questions: 1. Does the Apache foundation accept domain transfers? - It seems wrong to have a single person in charge of the domain ownership. - Regardless, I wil continue to renew the domain if Apache does not want the responsibility. 2. Does Apache infrastructure support custom domains? - So that we do not need to do the domain redirect. - Since CouchDB uses redirects as well, I am guessing the answer is "no" The only resource that I can find is on website management [1]. However, it does not address domain names. Thanks, Michael [1] http://apache.org/dev/#web
Re: Supporting multiple plugin return values
My only comment is that I think it's worth refactoring
cordova.callbackFromNative so that it passes the multiple values to
callbacks as separate parameters. All references to it are in cordova-js
plus one in Android's NativeToJsMessageQueue.java
On Wed, Feb 13, 2013 at 5:42 PM, Shazron wrote:
> Looks good to me.
> Although I have a bone to pick with dictionaryWithObjectsAndKeys having
> objects first but that's not our problem ;) Good thing they support literal
> notation now...
>
>
> On Wed, Feb 13, 2013 at 12:24 PM, Michal Mocny
> wrote:
>
> > ping. Shaz?
> >
> >
> > On Tue, Feb 12, 2013 at 11:28 AM, Michal Mocny
> > wrote:
> >
> > > I've pushed this to a remote branch: multipart_plugin_result for both
> ios
> > > and js repo's:
> > >
> > > ios:
> > >
> >
> https://git-wip-us.apache.org/repos/asf?p=cordova-ios.git;a=shortlog;h=refs/heads/multipart_plugin_result
> > > js:
> > >
> >
> https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=shortlog;h=refs/heads/multipart_plugin_result
> > >
> > > mobile-spec-tests run fine and there should be no difference to any
> > > existing plugins. Instead of adding anything complicated to support
> > > multiple arguments, I just added a new CDVType: MultiPart much in the
> > same
> > > fashion as ArrayBuffers (we can implement a more efficient way to
> encode
> > > type information at some point, but its not really a problem right
> now).
> > >
> > > The resulting arguments are unfortunately delivered to plugin callback
> as
> > > a single array argument instead of as separate arguments (ie function
> > > win(args) { var arg1 = args[0] ...} instead of function win(arg1, arg2,
> > > arg3) {...}) due to the way cordova.callbackFromNative helper is
> > > implemented. This can be improved later if we would like.
> > >
> > > Please take a look!
> > >
> > > -Michal
> > >
> > >
> > > On Sat, Jan 19, 2013 at 11:45 AM, Shazron wrote:
> > >
> > >> I don't see any problem with it as long as existing plugins (core and
> > >> third-party) don't break (unless we need to deprecate anything of
> > course)
> > >>
> > >>
> > >> On Fri, Jan 18, 2013 at 11:55 AM, Michal Mocny
> > wrote:
> > >>
> > >> > I've filed https://issues.apache.org/jira/browse/CB-2239 but wanted
> > to
> > >> get
> > >> > feedback here in case there a simpler solution to this problem.
> > >> >
> > >> > Basically: I've recently added support for ArrayBuffer argument type
> > >> across
> > >> > iOS exec bridge and Braden added the same to Android.
> > >> >
> > >> > However, while working on a plugin to make use of this feature
> > >> (socket), we
> > >> > found that sound plugin calls expect to send an ArrayBuffer back
> along
> > >> with
> > >> > over values.
> > >> >
> > >> > We considered adding a special bucket for ArrayBuffer return values
> to
> > >> the
> > >> > bridge, so that you can send a normal result + ArrayBuffer, but
> > decided
> > >> > that wasn't scalable since we may want more custom non-json
> > serializable
> > >> > types in the future.
> > >> >
> > >> > We decided the best option was to allow returning a list of "cordova
> > >> bridge
> > >> > supported types", which includes everything we have had until now +
> > >> > ArrayBuffer + whatever we add in the future.
> > >> >
> > >> > This shouldn't be a big change, existing plugins need not change at
> > all,
> > >> > and it also opens up the possibility to do some interesting
> encodings
> > >> for
> > >> > return values whenever JSON isn't the most efficient (we do some of
> > >> this on
> > >> > android already).
> > >> >
> > >> > -Michal
> > >> >
> > >>
> > >
> > >
> >
>
Re: Supporting multiple plugin return values
Looks good to me.
Although I have a bone to pick with dictionaryWithObjectsAndKeys having
objects first but that's not our problem ;) Good thing they support literal
notation now...
On Wed, Feb 13, 2013 at 12:24 PM, Michal Mocny wrote:
> ping. Shaz?
>
>
> On Tue, Feb 12, 2013 at 11:28 AM, Michal Mocny
> wrote:
>
> > I've pushed this to a remote branch: multipart_plugin_result for both ios
> > and js repo's:
> >
> > ios:
> >
> https://git-wip-us.apache.org/repos/asf?p=cordova-ios.git;a=shortlog;h=refs/heads/multipart_plugin_result
> > js:
> >
> https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=shortlog;h=refs/heads/multipart_plugin_result
> >
> > mobile-spec-tests run fine and there should be no difference to any
> > existing plugins. Instead of adding anything complicated to support
> > multiple arguments, I just added a new CDVType: MultiPart much in the
> same
> > fashion as ArrayBuffers (we can implement a more efficient way to encode
> > type information at some point, but its not really a problem right now).
> >
> > The resulting arguments are unfortunately delivered to plugin callback as
> > a single array argument instead of as separate arguments (ie function
> > win(args) { var arg1 = args[0] ...} instead of function win(arg1, arg2,
> > arg3) {...}) due to the way cordova.callbackFromNative helper is
> > implemented. This can be improved later if we would like.
> >
> > Please take a look!
> >
> > -Michal
> >
> >
> > On Sat, Jan 19, 2013 at 11:45 AM, Shazron wrote:
> >
> >> I don't see any problem with it as long as existing plugins (core and
> >> third-party) don't break (unless we need to deprecate anything of
> course)
> >>
> >>
> >> On Fri, Jan 18, 2013 at 11:55 AM, Michal Mocny
> wrote:
> >>
> >> > I've filed https://issues.apache.org/jira/browse/CB-2239 but wanted
> to
> >> get
> >> > feedback here in case there a simpler solution to this problem.
> >> >
> >> > Basically: I've recently added support for ArrayBuffer argument type
> >> across
> >> > iOS exec bridge and Braden added the same to Android.
> >> >
> >> > However, while working on a plugin to make use of this feature
> >> (socket), we
> >> > found that sound plugin calls expect to send an ArrayBuffer back along
> >> with
> >> > over values.
> >> >
> >> > We considered adding a special bucket for ArrayBuffer return values to
> >> the
> >> > bridge, so that you can send a normal result + ArrayBuffer, but
> decided
> >> > that wasn't scalable since we may want more custom non-json
> serializable
> >> > types in the future.
> >> >
> >> > We decided the best option was to allow returning a list of "cordova
> >> bridge
> >> > supported types", which includes everything we have had until now +
> >> > ArrayBuffer + whatever we add in the future.
> >> >
> >> > This shouldn't be a big change, existing plugins need not change at
> all,
> >> > and it also opens up the possibility to do some interesting encodings
> >> for
> >> > return values whenever JSON isn't the most efficient (we do some of
> >> this on
> >> > android already).
> >> >
> >> > -Michal
> >> >
> >>
> >
> >
>
Re: iOS has a window.Settings object
https://issues.apache.org/jira/browse/CB-2433
On Wed, Feb 13, 2013 at 2:54 PM, Shazron wrote:
> Deprecating sounds good to me - I've never used this feature and the
> alternative is better.
>
>
> On Wed, Feb 13, 2013 at 11:26 AM, Andrew Grieve >wrote:
>
> > @implementation CDVDevice
> >
> > - (void)getDeviceInfo:(CDVInvokedUrlCommand*)command
> > {
> > /* Settings.plist
> > * Read the optional Settings.plist file and push these user-defined
> > settings down into the web application.
> > * This can be useful for supplying build-time configuration
> variables
> > down to the app to change its behavior,
> > * such as specifying Full / Lite version, or localization (English
> vs
> > German, for instance).
> > */
> > // TODO: turn this into an iOS only plugin
> > NSDictionary* temp = [CDVViewController getBundlePlist:@"Settings"];
> >
> > if ([temp respondsToSelector:@selector(JSONString)]) {
> > NSString* js = [NSString stringWithFormat:@"window.Settings =
> > %@;",
> > [temp JSONString]];
> > [self.commandDelegate evalJs:js];
> > }
> >
> >
> >
> > I can't find any docs that mention this feature. Do other platforms have
> > something like this? Any objections to deprecating this? Seems like you
> > could accomplish x-platform & without a plugin by XHR'ing a .json file
> from
> > your app directory.
> >
>
Re: Supporting multiple plugin return values
ping. Shaz?
On Tue, Feb 12, 2013 at 11:28 AM, Michal Mocny wrote:
> I've pushed this to a remote branch: multipart_plugin_result for both ios
> and js repo's:
>
> ios:
> https://git-wip-us.apache.org/repos/asf?p=cordova-ios.git;a=shortlog;h=refs/heads/multipart_plugin_result
> js:
> https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=shortlog;h=refs/heads/multipart_plugin_result
>
> mobile-spec-tests run fine and there should be no difference to any
> existing plugins. Instead of adding anything complicated to support
> multiple arguments, I just added a new CDVType: MultiPart much in the same
> fashion as ArrayBuffers (we can implement a more efficient way to encode
> type information at some point, but its not really a problem right now).
>
> The resulting arguments are unfortunately delivered to plugin callback as
> a single array argument instead of as separate arguments (ie function
> win(args) { var arg1 = args[0] ...} instead of function win(arg1, arg2,
> arg3) {...}) due to the way cordova.callbackFromNative helper is
> implemented. This can be improved later if we would like.
>
> Please take a look!
>
> -Michal
>
>
> On Sat, Jan 19, 2013 at 11:45 AM, Shazron wrote:
>
>> I don't see any problem with it as long as existing plugins (core and
>> third-party) don't break (unless we need to deprecate anything of course)
>>
>>
>> On Fri, Jan 18, 2013 at 11:55 AM, Michal Mocny wrote:
>>
>> > I've filed https://issues.apache.org/jira/browse/CB-2239 but wanted to
>> get
>> > feedback here in case there a simpler solution to this problem.
>> >
>> > Basically: I've recently added support for ArrayBuffer argument type
>> across
>> > iOS exec bridge and Braden added the same to Android.
>> >
>> > However, while working on a plugin to make use of this feature
>> (socket), we
>> > found that sound plugin calls expect to send an ArrayBuffer back along
>> with
>> > over values.
>> >
>> > We considered adding a special bucket for ArrayBuffer return values to
>> the
>> > bridge, so that you can send a normal result + ArrayBuffer, but decided
>> > that wasn't scalable since we may want more custom non-json serializable
>> > types in the future.
>> >
>> > We decided the best option was to allow returning a list of "cordova
>> bridge
>> > supported types", which includes everything we have had until now +
>> > ArrayBuffer + whatever we add in the future.
>> >
>> > This shouldn't be a big change, existing plugins need not change at all,
>> > and it also opens up the possibility to do some interesting encodings
>> for
>> > return values whenever JSON isn't the most efficient (we do some of
>> this on
>> > android already).
>> >
>> > -Michal
>> >
>>
>
>
Re: [Android] Plugins need to know what service they are
Is it as simple as reading config.xml cordova/plugins dictionary and reversing the keys and values to create a lookup? https://github.com/apache/cordova-android/blob/master/framework/res/xml/config.xml On Wed, Feb 13, 2013 at 11:54 AM, Joe Bowser wrote: > Hey > > Currently, I'm trying to figure out a way to restore state, and it > turns out that I misunderstood how our current plugin architecture > works. We need a way to take a class name and map it back to the > service name of that plugin. For example, I need to know that > org.apache.cordova.CameraLauncher is the Camera plugin so that I can > store this in the bundle so that when we re-load the application, we > can re-load the plugin that was loaded in the previous state. > > This is in response to the ongoing camera issues on Android. Right > now there's some serious state issues that we don't handle very well > that we need to do better. This requires us to save which service was > expecting the callback when we stop the application so that service > can receive the callback when we resume. That's why we need this > functionality. > > Any ideas what we can do here? > > Joe >
Re: iOS has a window.Settings object
Deprecating sounds good to me - I've never used this feature and the
alternative is better.
On Wed, Feb 13, 2013 at 11:26 AM, Andrew Grieve wrote:
> @implementation CDVDevice
>
> - (void)getDeviceInfo:(CDVInvokedUrlCommand*)command
> {
> /* Settings.plist
> * Read the optional Settings.plist file and push these user-defined
> settings down into the web application.
> * This can be useful for supplying build-time configuration variables
> down to the app to change its behavior,
> * such as specifying Full / Lite version, or localization (English vs
> German, for instance).
> */
> // TODO: turn this into an iOS only plugin
> NSDictionary* temp = [CDVViewController getBundlePlist:@"Settings"];
>
> if ([temp respondsToSelector:@selector(JSONString)]) {
> NSString* js = [NSString stringWithFormat:@"window.Settings =
> %@;",
> [temp JSONString]];
> [self.commandDelegate evalJs:js];
> }
>
>
>
> I can't find any docs that mention this feature. Do other platforms have
> something like this? Any objections to deprecating this? Seems like you
> could accomplish x-platform & without a plugin by XHR'ing a .json file from
> your app directory.
>
[Android] Plugins need to know what service they are
Hey Currently, I'm trying to figure out a way to restore state, and it turns out that I misunderstood how our current plugin architecture works. We need a way to take a class name and map it back to the service name of that plugin. For example, I need to know that org.apache.cordova.CameraLauncher is the Camera plugin so that I can store this in the bundle so that when we re-load the application, we can re-load the plugin that was loaded in the previous state. This is in response to the ongoing camera issues on Android. Right now there's some serious state issues that we don't handle very well that we need to do better. This requires us to save which service was expecting the callback when we stop the application so that service can receive the callback when we resume. That's why we need this functionality. Any ideas what we can do here? Joe
Re: device.cordova in 2.3.0 on Win8
This is good enough. That was my oversight. On Wed, Feb 13, 2013 at 10:45 AM, Marcel Kinard wrote: > I was contacted by someone using Cordova 2.3 on Windows desktop 8, and > they said that device.cordova was returning "2.2.0" instead of the expected > "2.3.0". > > Sure enough, cordova-2.3.0.js (and all its copies) have "2.2.0" hardcoded > inside the definition of getDeviceInfo (line 6031) instead of "2.3.0". > > In the changeset > https://git-wip-us.apache.org/repos/asf?p=cordova-windows.git;a=commitdiff;h=c2973d277340795df8256b2893c41d27e59689f6#patch2 > I see where the hardcoded value went straight from "2.2.0" to "2.4.0" on > Jan 23rd, which is well after 2.3.0 was released (in the view search for > the string "cordova:"). > > I don't see a Jira item on this topic. > > For the person that contacted me, I'll just ask them to patch their source > locally. > > Given that we don't generally do x.y.1 releases unless there is a major > problem, we'll just let this go? Should I create a Jira item and mark it > as "won't fix" to document this, or is this email good enough? > > -- Marcel Kinard > > > -- @purplecabbage risingj.com
device.cordova in 2.3.0 on Win8
I was contacted by someone using Cordova 2.3 on Windows desktop 8, and they said that device.cordova was returning "2.2.0" instead of the expected "2.3.0". Sure enough, cordova-2.3.0.js (and all its copies) have "2.2.0" hardcoded inside the definition of getDeviceInfo (line 6031) instead of "2.3.0". In the changeset https://git-wip-us.apache.org/repos/asf?p=cordova-windows.git;a=commitdiff;h=c2973d277340795df8256b2893c41d27e59689f6#patch2 I see where the hardcoded value went straight from "2.2.0" to "2.4.0" on Jan 23rd, which is well after 2.3.0 was released (in the view search for the string "cordova:"). I don't see a Jira item on this topic. For the person that contacted me, I'll just ask them to patch their source locally. Given that we don't generally do x.y.1 releases unless there is a major problem, we'll just let this go? Should I create a Jira item and mark it as "won't fix" to document this, or is this email good enough? -- Marcel Kinard
