id,summary,reporter,owner,description,type,status,priority,milestone,component,version,resolution,keywords,cc,state
2260,build tools refactoring / web service,tmcw,,"Just as an experiment / proof of concept, I've got a custom OpenLayers builder working on [http://openlayerer.appspot.com/ App Engine], but not using any real app engine-specific code (so it would be easily rebuilt in django). At the moment it's mostly untested & clearly lacks a few features that I'll add in tonight (selecting formats, providing default configurations which will work, select-all, etc). The code is public on [http://github.com/tmcw/OpenLayerer/tree/master GitHub] and you can see in it that doing this required a few small changes to both mergejs and build.py, which I'd like to refactor back into OpenLayers so that they don't have to be hacks. Basically, the way that mergejs provides its own Config object and requires it to be provided with a config file ties developers' hands as far as dynamically creating configurations, which is what openlayerer does, in a very basic way. Also, build.py's logic desperately needs to be abstracted out a bit so that it doesn't always need to write to a file and so that it doesn't run all of it's code when imported from another module (the obvious if __name__ == ""__main__"" trick.

Anyway, I'm going to work on both those patches if there's any chance they will get accepted into trunk or dev, and would like to gauge interest in making an OpenLayers-builder something that's closer to openlayers.org itself, or just rebranding this little hack. My concern is that there's a growing impression that OpenLayers is a gigantic library and that's rather true with the full distribution, but few users are going to make their own .cfg and run the Python tools necessary.

Interested in hearing your thoughts,

Tom MacWright
http://www.developmentseed.org/",feature,new,minor,2.13 Release,general,2.8,,build,,Needs Discussion