[OpenLayers-Dev] 2.7 ticket list

[Stephen Woodbridge]

Pedro Simonetti Garcia wrote:
> 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.

Pedro,

If you would like me to review stuff that would be fine. It has been a 
few years since I have worked on a ka-map project and some of the more 
active devs would probably be a better resource, but I'm happy to help 
if I can.

Chris,

You are right about forking projects and I wasn't advocating it as the 
standard. Because of the reasons you stated about ka-map, I have 
maintained my own fork of precache.php and tile.php for some time. In 
part because it took a long while for the patch to add a directly level 
into the cache structure to deal with too many files in a directory, 
that I submitted. By the time that got added I had also added various 
convenience features for my automation tool that are probably not 
generally useful.

Regardless, in my mind ka-map as a project has been largely deprecated 
by OpenLayers functionality on the client side. I think it would be a 
shame to loose the server side components precache.php and tile.php as 
these are good solutions for the PHP side of the house. Hopefully this 
will not happen, but the only other consumer of ka-map tiles is 
OpenLayers, hence my suggestion that it might be a logical place for 
these components to also live.

-Steve

> regards,
> 
> Pedro Simonetti.
> 
> 2008/4/28 Christopher Schmidt <crschmidt at metacarta.com 
> <mailto:crschmidt at metacarta.com>>:
> 
>     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
> 
>