I'm planning to add an add an api to send binary data across the bridge, as well as to share a plugin for raw tcp/udp socket which I've been working on.
On Fri, Jan 4, 2013 at 10:37 AM, Andrew Grieve <[email protected]> wrote: > I'm planning to focus on bug fixes as well as working on support for JS > within plugins (e.g. following up on my "food for thought" email). > > > On Thu, Jan 3, 2013 at 3:19 PM, Brian LeRoux <[email protected]> wrote: > > > This requires a new thread to garner some consensus. Gonna kick that > > up. (Stoked that we're at this point.) > > > > On Thu, Jan 3, 2013 at 11:52 AM, Filip Maj <[email protected]> wrote: > > > There are always bug fixes and issues that can easily take up one's > time > > > for any given platform. It's a constant battle :) > > > > > > I will be focusing around the cli tooling and putting more work into > the > > > plugin specification + the plugin tooling, with the goal being to > achieve > > > the "light core" and plugins-as-separate-entities Brian mentioned. If > > > others in our community are up for it, perhaps they can help out by > > > starting to split out the core APIs into their own repos, and making > them > > > work with the CLI tooling / plugman tool? In my mind outstanding tasks: > > > > > > - split plugins out into individual repos > > > - audit BlackBerry and WP7 support for plugin tooling on plug man > > > - support for other platforms for plugin tooling > > > - for this, first we need to identify which platforms we want to > > support > > > with auto plugin management > > > - then add support to the tools for it > > > - integrate with the top-level cordova-cli tool > > > > > > On 1/3/13 11:40 AM, "Brian LeRoux" <[email protected]> wrote: > > > > > >>Joe: think API audits should start after we remove the APIs from core > > >>so we can version plugins independently. > > >> > > >>Fil: yes, that'd be awesome. > > >> > > >>Marcel: first priority for the long view on 3.x is a light core w/ no > > >>APIs. The tools aren't there yet to do this so continued work there in > > >>2.4 needed. If you want to see the particular feature-set for a > > >>release you can look in JIRA and whats been assigned. In Cordova the > > >>committers assign their own issues (w/ our goals in mind). I would > > >>imagine that 2.4 will have many bug fixes related to recent additions > > >>like InAppBrowser which debuts this week (or so) in 2.3 > > >> > > >> > > >>On Thu, Jan 3, 2013 at 11:30 AM, Filip Maj <[email protected]> wrote: > > >>> I'd like to include cordova-cli into our full source release in > 2.4.0. > > >>> > > >>> On 1/3/13 10:22 AM, "Joe Bowser" <[email protected]> wrote: > > >>> > > >>>>I believe that 2.4.0 is the release where we refactor our APIs and > > >>>>clean things up. > > >>>> > > >>>>On Thu, Jan 3, 2013 at 6:57 AM, Marcel Kinard <[email protected]> > > >>>>wrote: > > >>>>> Aside from bug fixes, are there ideas on what you think will be > > >>>>>tackled > > >>>>>for > > >>>>> 2.4? I suspect at least some of you have ideas in your head that I > > >>>>>haven't > > >>>>> fully seen written here. I'm just looking for a high-level bullet > > >>>>>list. > > >>>>>I'm > > >>>>> not looking for promises, instead just to set some rough > expectations > > >>>>>for > > >>>>> Cordova consumers. > > >>>>> > > >>>>> I see the roadmap wiki page organized by quarter, but I'm looking > for > > >>>>> something more narrow to at least answer "What do we think the next > > >>>>>version > > >>>>> (2.4) will look like". When doing agile projects with my employer, > > I'm > > >>>>>used > > >>>>> to keeping a prioritized backlog which can be used to answer > > questions > > >>>>>like > > >>>>> this, but I don't see that in Jira. Thanks! > > >>>>> > > >>>>> -- Marcel Kinard > > >>> > > > > > >
