Hi River
firstly, i'd like to see proper integration
between the OSM and WMF
parts of the Toolserver. for example, someone has configured a web
server on cassini, and people are already deploying tools at
<http://cassini.toolserver.org/~username/>. it should be clear why using
"cassini.toolserver.org" in a URL is a bad idea; but i don't see why
cassini needs to host user tools at all.
I don't see the necessity for a
tool-webserver on cassini, too. If we
could connect to the postgresql-db on cassini from the other toolserver
login-/webservers, it would be ok for most tools as well.
If we could set up mapnik on the login servers I don't see any reasons
to login on cassini except for administrative tasks.
Atm. Cassini is only in testing phase. I have written a tool on it just
to see how & if it works. Also the imports I'm currently doing are more
of educational nature (I'm learning how to populate the postgis-db, keep
the minutely replication running, etc.).
the Toolserver already has a web server which works
quite well, and has
plenty of spare resources. by putting OSM user tools there, we can
combine resources and make efficient use of them; if/when the web server
is full, we can add additional resources and both WMF and OSM users will
immediately be able to take advantage of them.
+1
(i understand OSM needs
some special Apache module for serving tiles; keeping that on cassini
probably makes sense.)
I think cassini should keep running the postgis-db, the
rendering stack
and a dev-tileserver, where we can play with different mapnilk-styles --
nothing more.
it's also not clear to me whether cassini needs to
be a login server at
all; the WMF databases at the TS don't allow user login, and users
connect to them remotely. is there something special about OSM tools
that prevents them from running on the existing TS login servers?
No, except for a
mapnik installation, that can be installed on the
regular login servers as well.
secondly, in the rush to deploy cassini as quickly as
possible, it seems
that little planning has been done. one thing we've learnt from the
Toolserver is that it's a lot less effort to plan things properly from
the start, instead of deploying something, then discovering it has to be
redone later. might i suggest that people take a step back, consider
what exactly the "OSM Toolserver" is meant to be, and come up a plan
before going any further?
Okay, here're my ideas:
Put some HD-Space from ptolemy or from a store ;) into cassini and get
two databases on it:
- a complete osm-clone including history
- a postgis db for rendering
Ptolemy only needs the latter for serving as database-backend for the
live renderer.
Connect Postgresql with LDAP and open it read-only to the regular login-
& webservers.
Get regular update running on cassini, later porting this effort to
ptolemy (I already wrote a task to do a complete planet update, located
in /sql/planet.osm on cassini)
Get some Mapnik-Styles (the multilanguage, the hike'n'bike style and
maybe others) on Cassini.
Define a procedure (like "post it on the mailing list") that allows
others to put their style on cassini. Document how to access cassinis DB
from the toolservers, how an when the updates take place etc.
What are yours?
Peter