[OpenLayers-Dev] OpenLayers 3.0 Development

[Kenneth Skovhede, GEOGRAF A/S]

It sounds like a great idea, and it actually works for Python.

However, since OpenLayers extensively use subclassing, won't this be
a problem, if one were to make WFS3 it might be required to also make
Layer3, Grid3, etc?

I can also see that the Map and Layer classes are tightly coupled, so I
forsee trouble there. Will there be extra development to allow a Map3 to
support a Layer, and vice versa for Layer3 and Map?

Regards, Kenneth Skovhede, GEOGRAF A/S



Christopher Schmidt skrev:
> 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,
>