[Tilesathome] Contacting T at H User

[Knut Arne Bjørndal]

On Mon, Jun 29, 2009 at 11:44:37AM -0400, Matthias Julius wrote:
> Heiko Jacobs <heiko.jacobs at gmx.de> 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 at 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 at h-server may inform his clients, that there are new styles...
> > Downloading styles outside svn may be peanuts for t at 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 at 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
bob+osm at cakebox.net
bobkare at irc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4167 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/tilesathome/attachments/20090629/6ff6fb79/attachment.bin>