Christopher, This is not a reason to fork a project! >
Okay, you've convinced myself :) Since OL is a front-end application, isn't appropriate to maintaing server code in it. I'll create an account in OL's track to get involved with the KaMapCache layer. Meanwhile, I'll communicate with the ka-Map list, and start writing a basic how-to ka-Map+OL. If there's anyone else interested in help, it will me much appreciated. regards, Pedro Simonetti. 2008/4/28 Christopher Schmidt <[EMAIL PROTECTED]>: > 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
