Hi Martin, On Thu, Aug 19, 2010 at 9:24 AM, Martin Aspeli <optilude+li...@gmail.com> wrote: > Hi Alec, > > On 20 August 2010 00:56, Alec Mitchell <ap...@columbia.edu> wrote: > >>> I'd like to experiment with making the AT UID() and reference/UID >>> catalogs use plone.uuid as well. Certainly, that's where I'd like us >>> to end up. I just didn't want to be too ambitious with the PLIP in the >>> first instance, in case we end up with complicated migrations or BBB >>> issues. >>> >>> Of course, plone.uuid on its own works perfectly well with Archetypes >>> objects. The problem is that as it's written right now, it doesn't >>> care about the AT UID() method and related catalogues. >>> >>> One thing we probably could do, is to make the Archetypes make_uuid() >>> method use the same UUID algorithm as plone.uuid. I'm not sure if we'd >>> want to migrate old content. They probably shouldn't clash, and making >>> changes could be problematic in case of embedded link-by-uid >>> references and similar. >>> >>> We could also/instead make an IUUID adapter implementation for >>> Archetypes content that looked context.UID(), and let AT continue to >>> manage its own UUIDs (but ideally using the same UUID generating >>> algorithm) to bridge the two. >>> >>> We could make the UUID indexer use the "UID" catalogue index instead >>> of creating a new one. This would be more consistent, at least if the >>> UUIDs looked and worked the same. >>> >>> If there's appetite for this type of a change, I'd be happy to implement it. >> >> I think this is probably the way forward; though for 4.1 we should >> probably do our best to preserve existing UIDs and avoid serious >> content migration headaches. One thing that concerns me on the >> technical side is that a "universal" UUID mechanism isn't really all >> that useful unless existing code (e.g. the AT reference browser) >> provides support for it. Without at least some minimal support within >> the existing framework, it would appear to make the lives of people >> who live on the bleeding edge (e.g. dexterity users) slightly easier >> at the expense of inconveniencing the vast majority of users by >> forcing a slow and largely unnecessary migration step. > > So, we must provide some new features so that we can justify the > feature we want to have. :-)
In my opinion, there must be a feature that's meaningful for Plone the application to justify adding features to the Plone the framework, yes. > Anyway, if the PLIP is accepted, I'd be happy to spend some time on > selective AT surgery (including the widget), unless the FWT feels this > is too risky. Ditto for link-by-uid in general. Great, I don't think allowing the reference browser to support referencing non-AT content sounds particularly risky, and it's a pretty compelling feature (i.e Plone supports references between heterogenous content types). >> It's my impression that people who are doing things with non-AT >> content are an extremely small and highly experienced minority of >> Plone users. > > The Dexterity list subscription rate and issue tracker suggest this is > at least starting to change. It's easy to choke off adoption with that > attitude, though. > > Three of the biggest "holes" in the Dexterity story that makes life > difficult right now are a lack of link-by-uid, no mature multilingual > support, and an inability to use Dexterity objects as reference > targets from AT content. The first we can solve for 4.1 with this > PLIP. The second will become more feasible with proper UUIDs according > to Hanno. And the latter is the ideal end goal of any AT refactoring > as per above. The first is unequivocally solved by simply having dexterity depend on plone.app.uuid. For the second, if LinguaPlone wants to support dexterity, it can also depend on plone.app.uuid (even as a soft dependency if that's less worrisome). The third is the only part that this PLIP would seem to be necessary for, but it's not actually a part of this PLIP, as you know. >> I suspect that the vast majority of those users are core >> developers and subscribe to this list. Those users are probably >> already aware that plone(.app).uuid is "the future" and can depend on >> it if they need it. If not, those who wish to promote it as such can >> do so, but I don't think that should be the job of the framework team >> (or the framework itself). > > I think you're missing my point: Since a UUID is only useful if it's > universally applied to all content, it needs to be a service provided > by Plone and in effect for all content and other objects, such as > comments and (possibly) users, groups, etc. Simply depending on the > package and using its API is not enough (if it was, I would never have > submitted the PLIP). At the very least, any and all packages wanting > proper UUIDs would need to provide a blunt installation step to > allocate and index UUIDs for all content, with some logic to > understand when this would be needed. Furthermore, divergent > implementations create non-trivial duplication of effort and catalogue > bloat. > > Hanno already indicated he was uncomfortable with this as a > LinguaPlone requirement. So, at least, we have two "big" third party > packages - LinguaPlone and Dexterity - asking for this functionality > so that they themselves can move forward, with a view to improving > Plone core in the future. LinguaPlone only needs this to support dexterity, so I'm not sure you get to count this twice :-) > The question to me is how we balance the risk of doing "too much" now > in terms of modifying existing core components, against the risk of > doing something that ultimately proves an inferior solution and > doesn't get used properly. I think this is the sort of evolutionary > argument we're always going to have for framework improvement work. > > All that said, I think we may "solve" this problem by widening the > PLIP to include more of the AT changes up front, which is probably a > good thing anyway. > > Also: this discussion now has more lines of text than plone.uuid and > plone.app.uuid have code. But that may be my own fault. ;-) Sorry if I've been less than concise as well; though I hope you spent more time writing and thinking about plone.uuid and plone.app.uuid than we've spent on this discussion. :-) Alec _______________________________________________ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
