That looks great. > Access to a particular form of persistence (e.g. the librarians > files-on-disk, or a particular postgresql schema) requires being in the same > source tree as the definition of that persistence mechanism. This avoids > having to synchronise deploys to multiple services when schema changes are > occuring: no leaky borders. That is to say that a particular persisted > collection should only be written and read by a single service. E.g. only one > kind of service will be able to read and write to the postgresql database > that contains bugtasks.
This is probably a reasonable principle, I guess. Other architectures of the kind you are describing do relax this; not so much in postgresql but through allowing slight version skew between different services accessing the same persistence layer. It almost seems to imply all the instances of the service that access the persisted layer must be updated strictly in lockstep, which might make deployment harder. Or is this essentially saying all "raw" persistence must be wrapped by a service, which is a bottleneck through which everything else accesses it. Queued messages can be considered a form of persistence, but presumably we'd be ok with multiple services reading/writing them. Perhaps this is just a matter of terminology about what is "persistence". Maybe you can make it more clear. Are you trying to say: when there is a lower-level service (eg psql, librarian data files) that requires lock-step updates with a dependent services, there should be only one higher-level service, which can then serve others with a more loosely coupled interface. > If care is taken around how information disclosure is managed, this front end > service could dispense with the entire zope security model, I understand and like the scatter-gather templating thing, but could you expand on "dispense with the entire zope security model"? Do you mean the templating layer will just pass-through the user identity, and security will be handled entirely on the back end? I understand public APIs are unconnected from adding internal APIs but I wonder how they would be implemented in this model: I suppose a new front end service that re-presents some internal APIs? > XMLRPC: pros: already deploys, batteries included in Python and many other > languages. cons: XML, RPC model rather than restful - no opportunity for > caching, URLs can be opaque when debugging. bzr bugs have shown the Python module for it is not that great. > adhoc restful json based apis. pros: nice to look at by hand, easy to > interact with manually. cons: not included in the Python standard library, > optimises for things that don't really affect us. python has a json library built in since 2.6 <http://docs.python.org/library/json.html> and of course also http. Probably faster (citation needed) than xml. Much less annoying for shipping around binary or unicode data than xml. Definitely the industry standard. As a consequence, more likely to fit easily with tools we could possibly want to use in the future like document databases. Makes it more easily possible to just directly proxy some APIs out to clients (obviously you would want some careful firewalling.) Beyond caching in the sense of inserting squid between different services, I think it's nice to be able to just hang on to the representation of a particular object and say "here is that object", which works in REST but does not make so much sense if the protocol is inherently about rpc. Other things to possibly add as services would be debug/production logging, an audit trail/activity log, and incoming-mail processing (which doesn't necessarily need to be a cron script.) But I guess they are just examples and not necessarily exhaustive. Martin _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
