[OpenLayers-Dev] OpenLayers 3.0 Development

[Christopher Schmidt]

Yo,

I've had a couple one-off conversations about this, but not one has
been in a public, archived location for everyone to read, I've realized.

There are a number of significant refactorings we have planned for
"OpenLayers 3.0". This is expected: as I said during my presentations in
Japan, "We've learned a lot in two years"... pointing out that 2 years
ago I'd never used a WMS (OpenLayers was my first), knew nothing about
projections, and the idea of EPSG:900913 didn't even exist.

So, we have some significant refactoring/changes to make. Cool. However,
one problem has always been that major refactorings all at once tend to
make things hard -- the 2.4 release was in testing/RC for 6 weeks
because of the huge number of things that we tried to pack in all at
once.

At one point in the past, I suggested that we target a method like the
one used by the Python 3.0 development team: Target creating a 'final'
OpenLayers release that had a 'compatibility mode' with OpenLayers 3.0.
In 2.x mode, everything would continue to work as it does now. In 3.0
mode, you would get errors -- preferably things like "You really need to
not be using the MouseToolbar class -- it's gone now, use NavToolbar
instead" -- that would tell you what was about to change.

This would require having a pretty strong knowledge of what is going to
be in 3.0 before we actually get there -- meaning we'll need some
parallel development. 

I believe that at least some of the changes that we're talking about are
possible to implement within the framework of 2.x -- though admittedly
with some more code. For example, one of the things that I think people
have been talking about is a single renderer root for SVG/VML. My vague
guess is that this would require changes to all of the renderer related
classes. It might also require changes to the Vector Layer, and some
other things -- like different controls or something.

However, it seems likely that since we'll want to provide transition
support, we can do this refactoring in something like a Renderer3 class
hierarchy (and similar for other classes).

If we do this, then upgrading to 3.0 functionality is similar to "from
future import generators" -- simply use the newer classnames in your
code.

Clearly, we wouldn't neccesarily be in a position to upgrade *all* code
in that way -- and as we do the development, we can keep information
about stuff that has or has not been upgraded. (This information will be
informative/'required' for transitioning later, anyway.)

Then, when we're ready to release 3.0, the transition isn't too painful:
we simply move the "3" classes back in place of the "2" classes. 

I don't want to limit development of OpenLayers 3.0 -- but the idea of a
"code sprint for 3.0" as has been mentioned does definitely scare me if
it's done in the way we did the vector work. 

Perhaps my estimation of the depth of changes needed for some 3.0 work
is too shallow, and this makes my proposal difficult, but what I'd
really love to see is: 
 
 * putting together a branch for various 3.0 features
 * Developing them
 * Figuring out how to put the features into 2.x as something people
   can explicitly choose -- not in the API, but as a way of letting us
   use them now, and get development/testing on them without waiting for
   one big changeover of applications.

Are there features that we can do this for? Are there features we can't
do this for?

I think one case of the latter *might* be the baselayer/overlay
dichotomy fixing -- but even that feels like it could be fixed to some
extent in an OpenLayers.Map3 class, maybe -- and maybe we don't go ahead
and change all the layers to work in a new way, but instead, create a
couple (Google, WMS) and then apply those changes to other layers as we
do the upgrade to 3.0.

Thoughts? 

Regards,
-- 
Christopher Schmidt
MetaCarta