[Framework-Team] Re: five.intid and object_implements index in Plone 3

[Alec Mitchell]

On 1/10/07, whit <d.w.morriss at gmail.com> wrote:
> Martin Aspeli wrote:
> > Hi Whit,
> >
> > On 1/10/07, whit <d.w.morriss at gmail.com> wrote:
> >> Martin Aspeli wrote:
> >> > Hi guys,
> >> >
> >> > I'm toying with the idea of introducing five.intid as a dependency for
> >> > Plone 3. Whit is responsible for this creation, so I'd like this input
> >> > as well, but from discussions with him it seems quite useful.
> >> >
> >> > - It can be combined with Zope 3's catalog implementation
> >> > - It can act as a generic reference catalog
> >> s/reference catalog/uid catalog/
> >>
> >> it is a catalog of references(keyreference object to be exact), but to
> >> create an content object -> content object reference system ala AT
> >> reference lite, we would need to whip up a bit more(though not too
> >> much).
> >
> > Oh, yes, true. Well, a content object could potentially store a list
> > of int ids its referencing, could it it not?
> >
> > Are int ids stable when objects move? Are modified?
> >
> > What about export/import?
> they should be stable for both iirc. (if not, events should be able to
> maintain this)
> >
> >> > - We (I) could simpilfy plone.app.redirector a little bit by using it
> >> > instead of a custom path storage (well, the storage would still need
> >> > to be there to remember where things used to be, but it would be a bit
> >> > more standards-based)
> >> my brain is tickled but I can't remember why....
> >
> > :-)
> >
> > Just because I stole your code and concepts doesn't mean I can't take
> > all the credit. ;)
> /me laughs.
>
> you deserve the credit ;)
>
> I should remember the code better. I'm just glad someone salvaged it...
> >
> >> > - We could use intids in more generic places like that fabled
> >> > selection widget. That is, we don't have to rely on context.UID().
> >> >
> >> this is a biggee.  In wicked, which hopefully soon will do all of it's
> >> "relational" behavior internally, I've moved to only accessing uid via
> >> an interface(IUID, a string or integer).  This opens up the ability to
> >> say, make wicked links to AT content and listen content(done w/ plone
> >> schemas).
> >
> > Yeah, that's my biggest win as well. Plus, it standarises us on what
> > Zope 3 is using (more or less).
> >
> >> > - Add a subscriber for Products.CMFCore.IContentish, so that it takes
> >> > care of all content
> >> +1 to using IContentish, or maybe even constraining the interface more.
> >> I discovered a ton of headaches as tried binding the subscriber from
> >> IPersistent on inwards;  Plone and CMF do alot of ugly things with
> >> persistence in site creation; intid is based on an object having an oid
> >> and is subscribed to object create, therefore depends on fairly normal
> >> ZODB behavior or you get ugly lowlevel errors.
> >
> > Right. I would've thought IContentish was safe, but we obviously need
> > to test.
> >
> >> > - Does it work well with portal_factory?
> >> seems to work ok... I would like to see more investigation.
> >
> > Cool. portal_factory basically clones objects in funny ways, so ids
> > may change between the in-factory and out-of-factory objects. Still,
> > that ought to be ok.
> >
> what do we currently depend on portal_factory for? any possibility we
> could move to a fate style addforms by 3.5?(different topic....)
> >> > - Does it give any noticable overhead (looks OK to me)?
> >> as long as the subscriber are reasonably constrained.
> >
> > My thought too.
> >
> >> > - Is it using Zope 2.10 or Zope 2.9's local component registrations
> >> > (should be easy to fix up anyway)?
> >> I wrote it against 2.9 so it's probably using that utility reg routine.
> >
> > Believe so. Anyway, doing it in 2.10 is easier :)
> >
> >> my main concern is getting five.intid hammered on and probably at this
> >> early stage, not piling too many irreversible dependencies upon it.
> >>
> >> my reasoning: Much of what is scary to me about this code adapting intid
> >> to zope2 is what made it so nice for mfaasen writing it in zope3.  It
> >> works at what ends up in Plone being a very low level and during
> >> development, when things broke, you couldn't even create a plone
> >> site(plone site creation alerted my to a myriad of possible issues with
> >> keyreferences and the myriad of things you can do with a
> >> transaction).    This got fire tested because during it's development I
> >> was working with multiple other developers who just wanted to work on
> >> site ui(was a real headache on a couple of occasions).
> >>
> >> I had to work very hard to get keyreferences and acquisition to play
> >> nice.   Due to the tight relationship with the persistence mechanism,
> >> when things do go wrong, you are often looking at errors upon
> >> transaction commit rather than in the code that is causing the error.
> >>
> >> so that is my caveat emptor.  wiggy informed me that the cheeseshop link
> >> for five.intid is broken. I'll try to fix this up, but otherwhise, just
> >> do an svn pull for most current version.
> >
> > So how tested/stable would you say it is? Did you hammer it in the
> > real world, or do you think there are problems you don't know how to
> > resolve or areas which are largely untested?
> >
> real world == real world development situations but not run in
> production(tagger is waiting for some ui love before it debuts on
> openplans).
>
> I would like to have more eyes on it; I think it's safe to move ahead
> though I wouldn't wait any later in the game to do so(in this
> release).   Basically, my point is proceed with caution and vigilance.

I have to say that, while these changes sound very valuable, it's
seems way too late in the release process to be proposing this stuff,
there's no PLIP, and no urgent need for it, it's certainly not a bug
fix.  It's up to wiggy of course, but I think it would be discouraging
if something potentially this important were rushed in at the last
minute without regard for the formal process.

Instead, why not make a simple addon product (with a simple GS
profile) that installs these dependencies and the necessary utils and
indexes, and attach it to a PLIP for 3.5?  Having intids would be
great, but it would be better if it came along with a real zope 3-ish
reference solution, not more portal_catalog bloat for convenience, and
there's certainly no time for that now but it's probably a great thing
to hack on in Sorrento.  :-)

Alec