I recently (well, two months ago) and wrote down a great deal of thoughts about the architecture for web mapping we are pushing at OpenGeo, and it's up on the website now.http://opengeo.org/publications/opengeo-architecture/
I recently (well, two months ago) and wrote down a great deal of thoughts about the architecture for web mapping we are pushing at OpenGeo, and it's up on the website now.never play chess with a clever elephant

6 comments:
What license did you use for this document? i.e. can I cut and paste bits into my course?
HTTP == transport ... sigh.
What's the correct terminology, oh best beloved web pedant?
@Ian, should be updated online soon, but CC-SA.
Nice! Thank you very much for sharing.
This appeared at just the right time - when I seem to be the lone proponent of using open standards, open source, mix and match software stacks, etc. (basically anything outside of a monolithic, proprietary, commercial stack from the 900 lb GIS gorilla) on a State GIS Architecture Working Group. I feel like I have a little red dot persistently aimed at my forehead (and at least one or two on my back). This will be quite helpful.
I'll list some of the good stuff you'll miss when you use HTTP as transport only (perhaps by tunneling all sorts of methods through POST):
- Safety of GET vs POST
- Ability to modify resources with PUT/DELETE
- Caching using HTTP's built-in expiration and validation
- Content negotiation (for better or worse)
Your GeoWebCache, for example: you only need such a thing because GeoServer considers HTTP to be only transport when doing its WxS thing. You could use something more generic from the open web stack like Varnish if your app server was taking full advantage of HTTP.
Post a Comment