On Wed, Aug 18, 2010 at 5:21 PM, Martin Aspeli <optilude+li...@gmail.com> wrote: > On 19 August 2010 09:20, Martin Aspeli <optilude+li...@gmail.com> wrote: >> On 19 August 2010 06:47, Geir Bækholt <pl...@baekholt.com> wrote: >>> On 18-08-2010 08.07, Martin Aspeli wrote: >>>>> • 10778 (Stand-alone UUID) >>> >>>> I think my reason for wanting it in the core, is twofold: >>>> >>>> - There's a proliferation of half-solutions to this problem right >>>> now. We need something blessed that people feel safe relying on. There >>>> is a cost associated with each half-solution in terms of catalogue >>>> bloat and in terms of confusion. >>> >>> We have repeatedly had frustration with the lack of a unified UID system >>> that we can depend on when writing add-ons. To base something on it as a >>> developer, you need to know you can depend on it being available always. >>> >>> I don't think it makes sense to postpone it "because nothing uses it yet". >> >> Right - I think it becomes a bit of a "chicken and egg" problem otherwise. > > Also: If we do the PLIP to separate out link-by-UID and similar > transforms, that's a natural candidate to use these UUIDs. :)
Though I voted against the inclusion of the UUID PLIP on it's own, if the link-by-uuid PLIP makes good use of it, then it certainly could be worth including. If there were a PLIP to make AT compatible with this implementation and convert Plone to using it, that would be a highly compelling argument for its inclusion. Otherwise we end up with Plone directly using one non-deprecated UID API while promoting another (which happens to not be useful anywhere within Plone itself). Don't we already suffer from enough of this kind of framework-level confusion? By including this wouldn't we essentially be saying, "Martin made this, and we think it's a nice thing; so now it's part of the core?" What other nice little libraries should we make part of Plone just because they might be useful to some developers or are used by a few add-ons that we happen to like? I'm sure we could think of quite a few, but I also think there's a good reason we don't generally do this. Adopting a library that we don't actually use, promotes a vision of Plone as a pure framework/toolkit that I'm not entirely comfortable with. Plone is an application (though a highly extensible one), and I don't really think we should be in the business of providing APIs beyond those consumed by it and those used to customize it. Alec _______________________________________________ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
