On Mon, Jun 29, 2009 at 11:44:37AM -0400, Matthias Julius wrote: > Heiko Jacobs <[email protected]> writes: > > > Sebastian Spaeth schrieb: > >> Chris-Hein Lunkhusen wrote: > >> > >>> Of course the Server should reject such old style tiles..... > >> > >> The server only knows about the client name (Ulm, Trondheim, etc) which > >> it can accept or reject. Bobkare and I were discussing today on how to > >> best implement finer grained version checking. > >> > >> Not all clients seem to have SVN available, which would give nice > >> revision numbers. > > > > Some times ago, as I asked someone why styles were not updated more quicker, > > I heard that svn from all clients to central svn would be a bottle neck... > > I had the idea, that not every client should make svn for styles, > > but the t...@h-server should do it regulary (cron every 6 hours ... 2 days > > ...) > > and if a diff from old to new says, that there are some changes, the > > t...@h-server may inform his clients, that there are new styles... > > Downloading styles outside svn may be peanuts for t...@h comparing to upload > > of all the tiles?
I doubt auto-update from svn would be a problem unless it was done very often, which would just be stupid anyway. > Currently, the stylesheets as gzip compressed tar archive are 252 KB. > I think it should be possible for the t...@h server to offer them as > tarball if the SVN server is brought to its knees by our clients doing > regular 'svn up's. I think it's a very bad idea to more or less reinvent the fully functional and fairly round wheel called svn and replace it with lots of code we would then have to debug and maintain. > But the problem remains that the server should be able to check the > version (svn revision) of the styles used for rendering. The client > should add this information to the meta data when it is uploading a > tileset. I think a better way to handle this is to have the client send both the client name (which isn't bumped very often) and version info of every involved component - that is all loaded perl modules (which you easily can have perl dump), rasterizer, java and stylesheet versions. The server wouldn't validate all of these, but it would check for a minimum version number of some things, and it could blacklist known bad versions of specific components. This would make it possible to blacklist for example known non-working versions of Batik or Inkscape much faster than today. I'm not sure using svn rev numbers is optimal, since those can differ in some cases (at least it does for svk users). We could either put a version number in the stylesheets (which authors have to increment manually), or base it on some other svn prop, is there for example one that contains the revision date? Manual version numbers would also work for clients that don't use svn. Anybody willing to code this? I'm not going to have time to do it anytime soon (or I would've done it already)... > If the server stores this information it could be used to trigger > render requests when styles change. If we just keep a log of when a style was mandated we can do a pretty good job of that just by looking at file modification dates, which ought to be a lot faster than looking at some other metadata store. -- Knut Arne Bjørndal aka Bob Kåre [email protected] bobk...@irc
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Tilesathome mailing list [email protected] http://lists.openstreetmap.org/listinfo/tilesathome
