On Sun, Apr 27, 2008 at 10:42:16PM -0500, Stephen Woodbridge wrote: > Chris, > > I sympathize with your sentiment that tile.php and precache.php not > being part of OpenLayers, but I think it is very useful to have them > with the examples, for a couple of reasons. > > 1) it keeps a version that we know works because it has been tested, > with the code > 2) it makes it easy for people to find these as they may not have come > from the ka-map project but might still want to use the,
So, let's look at other code that this might apply to: * TileCache * MapServer * GeoServer * Worldwind tile server * GDAL2tiles All of these have changing versions, some of which will work interact differently with the outside world between different versions, all of which might not be the first place that people will look. However, I don't think it's a sane expectation that OpenLayers is going to host the code for any of these. In fact, the primary reason, in my opinion, that this is special for ka-Map is two-fold: * The ka-Map project has experienced a long-term dearth of development, in part due to the success of OpenLayers as a web-mapping frontend. This means that for the past year or more, there has been limited support for ka-Map from the people who know it best, and that affects many things, like documentation, releases, etc. This happens in Open Source, and I'll admit that OpenLayers is at least partially responsible, as developer attention has been focused elsewhere. * ka-Map was never designed for external use as a separable client and server side components. As such, the documentation for the server-side components on their own was never particularly seperable, and the end result was that the server side was only described as part of the whole process. These two things combine to make ka-Map a less than palatable solution for users concentrating on OpenLayers, because the server-side components of ka-Map are not easy to set up using the documentation available from the ka-Map project at this time. However... This is not a reason to fork a project! Make no mistake: maintaining seperate copies of the ka-Map source code in OpenLayers is a fork. We should not fork any project for convenience: all the difficulties that exist in using ka-Map in OpenLayers are easily solvable. Most are solvable without code: documentation is the only thing that most of these problems need, and documentation can be easily written in the OpenLayers wiki, the ka-Map wiki, etc. Helping the ka-Map project out by working to document a seperable server-side component, one designed for use in other applications like OpenLayers, would be useful to many people, and probably not just OpenLayers. That's the appropriate place to solve the problem of ka-Map source code not being effectively documented or clearly available: forking the project is a mistake, and my first step towards doing so with the tile.php in examples/ was a faux paus that I should have corrected long ago. If there are people who are interested in solving problems within the ka-Map code, we should not continue to solve them in OpenLayers, where only OpenLayers users benefit. Get involved. Help bring life to the ka-Map server side project, kick out a release, get SVN access, and help out the people who spent so much time writing the code in the first place. Regards, -- Christopher Schmidt MetaCarta _______________________________________________ Dev mailing list [email protected] http://openlayers.org/mailman/listinfo/dev
