Mooooolto interessante, stavamo giusto discutendo di fare una cosa
simile per GeoServer :-).
Mi ha sempre piaciuto REST, ma anche python, e guando si vede come e'
minimo feature server, no si puo non inamorarsi 
Diciamo che ci sono due strade su cui le persone si stanno muovendo.
Una è aggiungere funzionalità come routing e geocoding a WFS come
sotred procedure or something like it, l'altro approccio è di mettere
un bel WPS
su per fare le operazioni in modo da non " incasinare" la divisione in
tier proprio dei servizi OGC (WFS data management, WPS business loigc
aka processing).
Ho scoperto oggi che per WPS esiste un fratello di featureserver che
sembra ugualmente elegante e REST: Guardati la demo:
http://crschmidt.net/mapping/wpserverdemo/
Certo che wps e' meglio che fare una cosa monolitico in stored
procedures... Ma piccolo e elegante in REST mi sembra piu' addatto per
uso interno che la stessa cosa molto piu' pesante..
Noi in questo momenti stiamo lavorando un pochino su WPS con
l'obiettivo di integrarli in una architettura enterprise con workflow
management. Ci sono alcuni progetti interessanti da usare e riusare,
stiamo valutando se integrare qualcosa in geoserver o meno. Stiamo poi
guardando a udig perche' esiste un plugin per accedere a WPS piu'
svariati tools basati su eclipse RCP per fare workflow management.
So di udig ma fin ora mi sono orientato molto piu' verso qGIS. Sara'
perche C/python mi e' molto piu' simpatico che Java...
Mio modestissimo parere. Qualcuno piu' noto e bravo di me ha detto
"l'ottimizzazione precoce è la radice di tutti i mali" e concordo,
ma cmq il punto è che si deve tenere conto a livello architetturale
dei problemi di performance e lasciare spazio alle soluzioni
altrimenti poi son guai!
Si, sono d'accordo che l'architettura limita fortemente la scalabilita'
e che non si cambia al volo in un secondo passo. Detto questo, non
penso che noi per usi interni abbiamo bisogno di una architettura
"enterprise" (come in J2EE con EJB e tutto cio') e il time to market e'
molto piu' importante
> Verso il fuori (cittadini, potenzialmente tanti), la situazione e'
> certamente molto diverso--ma anche il fabbisogno di creare e modificare
> geometrie (la maggiore ragione per quale vorrei vector tramite web) e'
> molto limitato (a mettere qualche punto con annotazione su qualche
> piano oppure in casi eccezionali un poligono...).
>
Hai pensato a gestire la sicurezza con un approccio RBAC? Ci sono
cosine interessanti da tenere conto in fase di progetto anche se
magari le si implementa poi.
Si, per tutti servizi tramite web, noi usiamo RBAC. E' molto usato da
noi; ad esempio per i scedolini dei impiegati e par le forze
dell'ordine che accedono a alcuni dei nostri dati dall'esterno. Per
tutto questo richiediamo smartcards per autenticazione (incluso la CIE
che emettiamo noi). A proposito, sono io l'architetto della nostra
soluzione e ho implementato la prima versione dell'apache handler che
fa l'autenticazione. Piccolo, semplice, e sicuro
La cosa bella del REST e' che lostesso sistema funziona anche qui
Detto questo, attualmente al interno usiamo qGIS che accede a postgres
tramite username/password. Ma internamente, la sicurezza e' diverso
che sul internet ostile ed i rischi non sono tanto alti (al meno se
inizio fare backups ;-).
Ma siccome mi piace semplicita', provo di semplificare il problema di
controllo di accessi al massimo: avere quanto possibile dati sotto una
licenza aperta (ancora da raggiungere
saluti
-b