launchpad-dev team mailing list archive

[Robert Collins <robert.collins@xxxxxxxxxxxxx>]

On Wed, May 18, 2011 at 7:31 PM, Ian Booth <ian.booth@xxxxxxxxxxxxx> 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