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. <div>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...</div>
<div>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. </div><div>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.</div>
<div><br></div><div>Ludwig</div><div><br></div><div><br><br><div class="gmail_quote">2008/11/24 Kenneth Skovhede, GEOGRAF A/S <span dir="ltr"><<a href="mailto:ks@geograf.dk">ks@geograf.dk</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
It sounds like a great idea, and it actually works for Python.<br>
<br>
However, since OpenLayers extensively use subclassing, won't this be<br>
a problem, if one were to make WFS3 it might be required to also make<br>
Layer3, Grid3, etc?<br>
<br>
I can also see that the Map and Layer classes are tightly coupled, so I<br>
forsee trouble there. Will there be extra development to allow a Map3 to<br>
support a Layer, and vice versa for Layer3 and Map?<br>
<br>
Regards, Kenneth Skovhede, GEOGRAF A/S<br>
<br>
<br>
<br>
Christopher Schmidt skrev:<br>
<div><div></div><div class="Wj3C7c">> Yo,<br>
><br>
> I've had a couple one-off conversations about this, but not one has<br>
> been in a public, archived location for everyone to read, I've realized.<br>
><br>
> There are a number of significant refactorings we have planned for<br>
> "OpenLayers 3.0". This is expected: as I said during my presentations in<br>
> Japan, "We've learned a lot in two years"... pointing out that 2 years<br>
> ago I'd never used a WMS (OpenLayers was my first), knew nothing about<br>
> projections, and the idea of EPSG:900913 didn't even exist.<br>
><br>
> So, we have some significant refactoring/changes to make. Cool. However,<br>
> one problem has always been that major refactorings all at once tend to<br>
> make things hard -- the 2.4 release was in testing/RC for 6 weeks<br>
> because of the huge number of things that we tried to pack in all at<br>
> once.<br>
><br>
> At one point in the past, I suggested that we target a method like the<br>
> one used by the Python 3.0 development team: Target creating a 'final'<br>
> OpenLayers release that had a 'compatibility mode' with OpenLayers 3.0.<br>
> In 2.x mode, everything would continue to work as it does now. In 3.0<br>
> mode, you would get errors -- preferably things like "You really need to<br>
> not be using the MouseToolbar class -- it's gone now, use NavToolbar<br>
> instead" -- that would tell you what was about to change.<br>
><br>
> This would require having a pretty strong knowledge of what is going to<br>
> be in 3.0 before we actually get there -- meaning we'll need some<br>
> parallel development.<br>
><br>
> I believe that at least some of the changes that we're talking about are<br>
> possible to implement within the framework of 2.x -- though admittedly<br>
> with some more code. For example, one of the things that I think people<br>
> have been talking about is a single renderer root for SVG/VML. My vague<br>
> guess is that this would require changes to all of the renderer related<br>
> classes. It might also require changes to the Vector Layer, and some<br>
> other things -- like different controls or something.<br>
><br>
> However, it seems likely that since we'll want to provide transition<br>
> support, we can do this refactoring in something like a Renderer3 class<br>
> hierarchy (and similar for other classes).<br>
><br>
> If we do this, then upgrading to 3.0 functionality is similar to "from<br>
> future import generators" -- simply use the newer classnames in your<br>
> code.<br>
><br>
> Clearly, we wouldn't neccesarily be in a position to upgrade *all* code<br>
> in that way -- and as we do the development, we can keep information<br>
> about stuff that has or has not been upgraded. (This information will be<br>
> informative/'required' for transitioning later, anyway.)<br>
><br>
> Then, when we're ready to release 3.0, the transition isn't too painful:<br>
> we simply move the "3" classes back in place of the "2" classes.<br>
><br>
> I don't want to limit development of OpenLayers 3.0 -- but the idea of a<br>
> "code sprint for 3.0" as has been mentioned does definitely scare me if<br>
> it's done in the way we did the vector work.<br>
><br>
> Perhaps my estimation of the depth of changes needed for some 3.0 work<br>
> is too shallow, and this makes my proposal difficult, but what I'd<br>
> really love to see is:<br>
><br>
> * putting together a branch for various 3.0 features<br>
> * Developing them<br>
> * Figuring out how to put the features into 2.x as something people<br>
> can explicitly choose -- not in the API, but as a way of letting us<br>
> use them now, and get development/testing on them without waiting for<br>
> one big changeover of applications.<br>
><br>
> Are there features that we can do this for? Are there features we can't<br>
> do this for?<br>
><br>
> I think one case of the latter *might* be the baselayer/overlay<br>
> dichotomy fixing -- but even that feels like it could be fixed to some<br>
> extent in an OpenLayers.Map3 class, maybe -- and maybe we don't go ahead<br>
> and change all the layers to work in a new way, but instead, create a<br>
> couple (Google, WMS) and then apply those changes to other layers as we<br>
> do the upgrade to 3.0.<br>
><br>
> Thoughts?<br>
><br>
> Regards,<br>
><br>
</div></div><div><div></div><div class="Wj3C7c">_______________________________________________<br>
Dev mailing list<br>
<a href="mailto:Dev@openlayers.org">Dev@openlayers.org</a><br>
<a href="http://openlayers.org/mailman/listinfo/dev" target="_blank">http://openlayers.org/mailman/listinfo/dev</a><br>
</div></div></blockquote></div><br></div>