It's also possible to create some APIs that would tell a website how much bandwidth is available to it, so the developer could adjust its features accordingly. This idea is being tossed around between web companies and operators, but I don't know how much is actually being done about it.
What is the guiding principle to make an informed design decision regarding the direction of communication in such a replication scenario? The answer is separation of concerns with the goal of simplicity and avoiding unnecessary coupling. This leads to the question which of the systems should for which communication play the server role and which one should play the client role?
karl Says:
novembre 28th, 2009 at 10:15
REST est un style architectural qui est encore une couche au dessus de HTTP.
Je rejoins Christian dans son analyse. Chacun des domaines est d’ailleurs interprété en fonction de la culture propre des intervenants. Lorsque l’on SPDY de Google qui est une forme d’extension à HTTP. Ils ne s’intéressent proprement dit qu’à l’efficacité du transport et pratiquement pas à l’amélioration du transfert.
Google centralise tous les services dans une même coquille. Sa seule interaction au final n’est avec qu’avec les logiciels clients. L’interopérabilité avec les autres serveurs n’est presque pas un objectif à terme. Ils ont besoin de rapidité, ils ont des besoins spécifiques qu’ils maîtrisent au cœur de leurs applications. Lorsqu’on a créé un écosystème avec un fort contrôle sur tous les éléments du système, on peut se permettre d’imposer sa loi à l’écosystème. Microsoft l’a fait dans l’univers de la bureautique. Google le fait petit à petit pour le Web. Nous n’y sommes pas encore bien sûr.
Pour Google, le transfert n’est pas important ou plutôt il est si peu mis en pratique (quid de HTTP PUT, DELETE, etc., des mime types et des headers) sur le Web aujourd’hui, que Google peut se concentrer sur ce qui améliore le transport des données.
So, in a nutshell, here is a tick-list for an architecture for participation:
* Open Source Implementations
* Test Suites
* Continuous Integration
* Wiki Driven Documentation
* Small, Lightweight Specifications
* Free and Open Licensing
I've published a manifesto for this approach in the form of a gnomic sampler on http://standeace.com, a contraction of "Standards" and "Peace":
]]>
WebAccessControl is a decentralized system for allowing different users and groups various forms of access to resources, where users and groups are identified by HTTP URIs.
Once freed from the awkward initial step of building their own base map, non-specialists rapidly colonized the online mapping space.
Addressing the problem of scalable access to web resources is not a simple one. There are a number of ways it can be approached at a number of different levels in the web architecture stack. The W3C Technical Architecture Group has agreed to investigate the issue. ¶ In the meantime, if you're writing GlassFish[L] servlets or other applications that are performing XML processing, you can take advantage of the XML Catalog resolver built into GlassFish to directly reduce the burden your applications are creating. (Never heard of a XML Catalogs? I wrote some background information a while back.) ¶
]]>