[OpenLayers-Dev] OpenLayers 3.0 Development

[Ludwig]

As a OL user I would say that I would prefer a clean break together with a
good documentation of how I would have to change my code to make it run
under OL3 again. I think the Python analogy is pushing it a bit: with OL, I
would think that most users have at most hundreds of lines of code, with
Python it can be zillions. Plus it is web-delivered, so there is not really
an issue of upgrading users etc...
My personal attitude to OL development is to once in while look at it, see
what is new and what I can add in new features to my maps, do that, roll it
out and forget about it for while again.
Cleanliness of the new code (and the removal of things that have not
weathered well) is much preferable for this than any form of compatibility
mode.

Ludwig



2008/11/24 Kenneth Skovhede, GEOGRAF A/S <ks at geograf.dk>

> 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,
> >
> _______________________________________________
> Dev mailing list
> Dev at openlayers.org
> http://openlayers.org/mailman/listinfo/dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/openlayers-dev/attachments/20081124/5e4a7937/attachment.html