Paraphrasing from meeting notes today:
* plugins are getting awesome treatment:
* universe
* dependencies
* versioning
* add/remove/upgrade
* access to native
* multiple plugins in one repo
* apps are getting some treatment:
* the app manifest has access to platform properties
* me
Okay, I've let the doodle run for ~5 days.
Looks like the best date is Friday, March 22nd, at 9AM Pacific time, noon
EST, 6PM Euro time.
I'm setting aside an hour for it, but it could last less.
I will look into setting up an Adobe Connect room so we can run
screenshare and do a recording as wel
people.
Attendance is not mandatory. I will provide an overview of the cli
tooling, and Anis will do the same for the plugin tooling. We can discuss
viability of apps as plugins, areas of the code to improve, designs or
patterns people would like to see changed, etc.
We should get one of the non
Sounds great, thanks for coordinating.
On Thu, Feb 14, 2013 at 1:07 PM, Filip Maj wrote:
> I'll set up a doodle for early to mid-march and post it back to this
> thread.
>
> On 2/14/13 10:03 AM, "Jesse" wrote:
>
> >Good.
> >
> >On Thu, Feb 14, 2013 at 9:42 AM, Filip Maj wrote:
> >
> >> So Ani
I'll set up a doodle for early to mid-march and post it back to this
thread.
On 2/14/13 10:03 AM, "Jesse" wrote:
>Good.
>
>On Thu, Feb 14, 2013 at 9:42 AM, Filip Maj wrote:
>
>> So Anis and I were thinking of, at the minimum, doing a 10-15 min
>>overview
>> of the tools we each work on (cordova
Good.
On Thu, Feb 14, 2013 at 9:42 AM, Filip Maj wrote:
> So Anis and I were thinking of, at the minimum, doing a 10-15 min overview
> of the tools we each work on (cordova-cli and plugman) and then fielding
> questions.
>
> We can also bring up main points for and against considering an app bei
So Anis and I were thinking of, at the minimum, doing a 10-15 min overview
of the tools we each work on (cordova-cli and plugman) and then fielding
questions.
We can also bring up main points for and against considering an app being
a plugin and see where that gets us.
I am thinking of setting up
BTW, because I happen to like contradictions. Plugins are not completely
free-form. They still require some sort of directory structure for every
supported platform (right now: iOS, Android and BlackBerry 10).
Precisely, src/{ios,android,BlackBerry10} needs to be there or libraries
(on android, bb1
I'd like to see where the overlap is before jumping in and merging the two
code bases.
I think that by essence plugins and apps are different. Even though they
are close in that they both have manifest/assets/native files.
I also like the existence of discrete tools that do one job rather than on
Sounds good.
-Michal
On Tue, Feb 12, 2013 at 3:20 PM, Filip Maj wrote:
> Cool, let me loop back with Anis and come up with a breakdown of the code
> for both cli and plugman.
>
> Once we have it figured I'll come back to the list and we can schedule an
> online meeting?
>
> On 2/12/13 12:11 PM
Cool, let me loop back with Anis and come up with a breakdown of the code
for both cli and plugman.
Once we have it figured I'll come back to the list and we can schedule an
online meeting?
On 2/12/13 12:11 PM, "Michal Mocny" wrote:
>That sounds great, Fil!
>
>-Michal
>
>
>On Tue, Feb 12, 2013
That sounds great, Fil!
-Michal
On Tue, Feb 12, 2013 at 2:59 PM, Andrew Grieve wrote:
> +1 to moving plugman into CLI. I think the two tools will have more and
> more overlap going forward.
>
>
> On Tue, Feb 12, 2013 at 3:00 PM, Filip Maj wrote:
>
> > This is correct Michal.
> >
> > Still not
+1 to moving plugman into CLI. I think the two tools will have more and
more overlap going forward.
On Tue, Feb 12, 2013 at 3:00 PM, Filip Maj wrote:
> This is correct Michal.
>
> Still not sure I like the fact that we are either a) creating a new
> manifest for applications that are at odds wi
This is correct Michal.
Still not sure I like the fact that we are either a) creating a new
manifest for applications that are at odds with config.xml or b) extending
config.xml with our own shit.
In the end the concern here is smart re-use of code (I.e. Hey, plugin
installation is sort of like a
Plugins can specify whole directories as well, so it would be trivial to
copy the whole www folder, I believe.
On Tue, Feb 12, 2013 at 2:31 PM, Braden Shepherdson wrote:
> Plugin devs are left to put together their own file structure. Plugins are
> pretty freeform, you specify where to find thin
Plugin devs are left to put together their own file structure. Plugins are
pretty freeform, you specify where to find things with and
tags; the installed locations have nothing to do with the
plugin repo locations.
The main difference that I can see is that plugins specify every file they
want c
On Tue, Feb 12, 2013 at 1:48 PM, Filip Maj wrote:
>
> >So, if an app was bundled as a plugin with its www folder, then if it
> >could
> >use config-file modification to set the startPage (this may not be
> >supported yet), would that be enough? Ideally plugins would support
> >importing a while
>So, if an app was bundled as a plugin with its www folder, then if it
>could
>use config-file modification to set the startPage (this may not be
>supported yet), would that be enough? Ideally plugins would support
>importing a while config.xml file?
I think so.. Currently config file modificati
>From the plugin spec description: "a plugin could be a single JavaScript,
or some native code with no corresponding JavaScript." which I think
applies equally well to apps.
Plugins already support:
* asset's and platforms (which was just a feature requested to add to apps
for cordova-cli)
* confi
It seems as if we could just add a trivial amount of extra functionality to
plugins, after which we could implement apps using the same flow/tools as
plugin dev. This would have all kinds of benefits.
Lets brainstorm what it would take to do this, and what roadblocks we would
face, in order to ex
20 matches
Mail list logo
