I agree with a lot of what you said. On Fri, Apr 5, 2013 at 3:13 PM, Joe Bowser <bows...@gmail.com> wrote:
> On Fri, Apr 5, 2013 at 12:00 PM, Max Woghiren <m...@chromium.org> wrote: > > We should slow this process down a little bit. Our next step should be > to > > structure the plugins in the existing repos so that the process of > > relocating them to their individual repos is straightforward. Trying to > do > > it as we go will be messy and lead to the types of problems that prompted > > Joe to make this thread to begin with. Let's not "plugin-ize" anything > > until we've done the meat of the work in the existing repos. > > Part of the problem is that the plugin repositories were decided > without looking at any of the existing code whatsoever. We basically > just grabbed a bunch of drafts and created a bunch of repositories > without thinking of what should actually go there. In the past, I > know that we've talked about killing the App plugin, but the fact is > that we can't do that because it fills a real need on certain > platforms, such as Android where we need to override the back button. > I understand the whole cross-platform thing, but we need to have these > utility methods in reality if we want Cordova to not suck. > You're totally right. I think that hastily creating the plugin repos was a mistake. I think we should do the majority of the work within the existing repos. This will culminate with us having properly determined what our plugins should be. Then we can accurately make the correct plugin repos. At this point, we can just do as Fil mentioned and request some repo additions/removals/renamings. In the case of the App plugin, it appears that not creating a repo was a deliberate decision. The conversation Andrew linked to has "app" explicitly listed as a plugin not getting its own repo. I don't think the desire at this point is to kill it, but to keep it bundled as a plugin in core Cordova. > > One major task that will help this process is to ensure that no plugins > are > > coupled. We can remove visibility from all methods in native code (eg. > > privatize methods on Android, remove signatures from headers on iOS). In > > this way, we can locate and deal with dependencies that will make the > > eventual plugin migration difficult. > > Do we want to do this? Right now there are shared classes for file > manipulation that we use that might be useful for other plugin > developers to also use. There are certain methods that I would like > to see die, but making everything private may not be practical, useful > or even possible for certain plugins. You're right again. In Android, I've split out common File code into a FileHelper class. It's not a plugin, and will be exposed to developers. This is the only shared-code example I know of, but if we find others (via the visibility removal test), we can similarly pull out the common code. > > So let's hold off on actually doing any inter-repository code movement; > it > > should be the final step, and should be done once it essentially already > * > > has* been done in the existing repos. I don't know that I see the point > of > > rushing to have it done before 3.0. > > The fact is that 3.0 is supposed to be plugins. If we don't have this > feature, there's no reason to do a 3.0 release, and we might as well > just call it a 2.10 release. I know for a fact that a lot of people > are going to be very unhappy if we don't keep going with this. The > question is how do we do this without it being completely ridiculous. > I wish we started on this last release, because we're running out of > time now. > Agreed a third time. 3.0 will be plugins, and so 3.0 can be the introduction of the individual plugin repos. Why aim for this in 2.7 (or 2.x, for that matter)? To do this without it being completely ridiculous, we pace ourselves and do this work in a structured way. No one is expecting this until 3.0, so let's spend the interim releases solving these problems.
