On Wed, May 18, 2011 at 7:31 PM, Ian Booth <ian.bo...@canonical.com> wrote: > Thinking out loud, would it be feasible to still use the zope component > model (eg interfaces) to define the services' APIs - they could be > easily run up outside the container for unit testing but when run inside > zope, we would still get the declarative security etc that zope offers. > Or am I totally off base there?
The Java 'container' concept isn't at all mature in the Python world. I don't know that we want to be the folk making it mature. I don't envision any use of zope interfaces for internal service definitions. I'm happy to elaborate on why if folk /want/ them. > My view is that zope data objects should not be seen above the > persistence layer but I don't have enough zope knowledge to know if > that's viable or desirable. Because we are looking at splitting our > system into multiple collaborating services, that has implications > anyway for how objects are passed around. One option is that passing an > in memory reference would become verboten, even if the services were to > be co-located in the same application container. See above about containers; we wouldn't colocate services. > Typically objects would > be represented by their business key - this is not (or rather should not > be) the database pk but many implementations including ours tend to be > lax about the use of surrogate keys. It is up to the callee (the > receiving end) to turn an object id back into an object in whatever way > makes sense for the use case. For operations like delete, no > transformation may even be required. This approach helps reinforce that > the inter-service interfaces need to be coarse grained. And of course, > inter-service calls do not have to be via RPC; the service operation > being invoked could be at the other end of a message queue. Yes, I agree. > So what should the id generation strategy be? (class, id) as suggested > at the start I have found to work well. It maps nicely to a restful > namespace too. id itself does not have to be globally unique (sometimes > people make it that way but it's not what we want) and as stated above, > should be a surrogate key but often defaults to the database pk. > > Anyway, enough rambling for now. If you've read this far, get a life :-) :P Thanks for the nice framing of the discussion space. I think that some delineations like you make may well help in evaluating some of the services; OTOH I think the crucial thing is to be thinking 'small clean interface, narrow domains, narrow definitions' when pulling something together. I'd expect most services to have < 5 types that they know about (vs the 200 our core has today). And as you know, I'm with you on POPO's - see my straw man to Michael about what the template layer might use. I still think that working on that in the very core right now is a hard problem with (relatively) few rewards compared to some of the other things we can tackle (like this large project to start really shrinking the code base). -Rob _______________________________________________ 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
