Re: [Framework-Team] PLIP #10778 (UUIDs) - ready for initial review
On 30 August 2010 19:46, Maurits van Rees wrote: > Op 29-08-10 07:24, Martin Aspeli schreef: >> plone.uuid provides a simple API for generating and accessing UUIDs. > > If we use this to create uuids for non-content items, that cannot be > traversed to, would that give any problems? No, although the helper function that gets you a (content) item from a UUID looks in portal_catalog, so you'd need a different mechanism if you needed that kind of central lookup. The UUIDs will never clash, though. > For example, it might be nice to use this to create the secrets that the > password reset tool sends out, or secrets used in a newsletter product. > I had a few ideas some months back that may or may not ever get > implemented. ;-) For this, uuid.uuid4() is probably fine. What plone.uuid adds is a (tiny) standard API for looking up a UUID for an object. If you had a "newsletter" object and you wanted its UUID you could write an IUUID() adapter for it. > I'd guess that, as long as such a non-content item with a uuid does not > end up in the portal_catalog, there is no way to accidentally try to > traverse to such non-content. Of course not. Martin ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIP #10778 (UUIDs) - ready for initial review
On 30 August 2010 12:46, Maurits van Rees wrote: > Op 29-08-10 07:24, Martin Aspeli schreef: >> plone.uuid provides a simple API for generating and accessing UUIDs. > > If we use this to create uuids for non-content items, that cannot be > traversed to, would that give any problems? > > For example, it might be nice to use this to create the secrets that the > password reset tool sends out, or secrets used in a newsletter product. > I had a few ideas some months back that may or may not ever get > implemented. ;-) > > I'd guess that, as long as such a non-content item with a uuid does not > end up in the portal_catalog, there is no way to accidentally try to > traverse to such non-content. There would be no need to involve plone.uuid here. Just use the uuid4 function from the standard library. Laurence ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIP #10778 (UUIDs) - ready for initial review
Op 29-08-10 07:24, Martin Aspeli schreef: > plone.uuid provides a simple API for generating and accessing UUIDs. If we use this to create uuids for non-content items, that cannot be traversed to, would that give any problems? For example, it might be nice to use this to create the secrets that the password reset tool sends out, or secrets used in a newsletter product. I had a few ideas some months back that may or may not ever get implemented. ;-) I'd guess that, as long as such a non-content item with a uuid does not end up in the portal_catalog, there is no way to accidentally try to traverse to such non-content. Maurits van Rees ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIP #10778 (UUIDs) - ready for initial review
On 29 August 2010 17:41, Wichert Akkerman wrote: > On 2010-8-29 07:24, Martin Aspeli wrote: >> The principal API is the IUUID() adapter factory, which can be used to >> return a (byte string) UUID. There is also an IUUIDGenerator utility >> to generate new UUIDs. The default implementation uses the standard >> library uuid.uuid1() method. > > Please change that to use uuid4() instead. uuid1() uses the unique > hardware address of the machine it runs on to generate the UUID, which > means the result UUID can be used to track down the specific machine > used to generate it. This has been used succesfully to track down people > and machines, and for that reason everyone has switched to the random > based approach as implemented by uuid4(). Done. Martin ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIP #10778 (UUIDs) - ready for initial review
On 2010-8-29 07:24, Martin Aspeli wrote: > The principal API is the IUUID() adapter factory, which can be used to > return a (byte string) UUID. There is also an IUUIDGenerator utility > to generate new UUIDs. The default implementation uses the standard > library uuid.uuid1() method. Please change that to use uuid4() instead. uuid1() uses the unique hardware address of the machine it runs on to generate the UUID, which means the result UUID can be used to track down the specific machine used to generate it. This has been used succesfully to track down people and machines, and for that reason everyone has switched to the random based approach as implemented by uuid4(). Wichert. -- Wichert AkkermanIt is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] PLIP #10778 (UUIDs) - ready for initial review
All, Following our rather lengthy discussion, I've made some changes to PLIP #10778, which I hope alleviate the concerns associated with this PLIP. This is now ready for testing. I've piggy-backed on David's PLIP #9938 buildout (plips/plip9938-output-filters.cfg), since his improved transforms will use the plone.uuid API to be non-Archetypes-specific. I've offered to support him in that PLIP, so there may yet be some changes desired in the PLIP #10778 code (plone.uuid, plone.app.uuid and the plip10778-plone.uuid branch of Products.Archetypes), although "on its own", I think this PLIP is now ready for review. Instead of describing the changes from the "old" code, I'll try to explain how the PLIP is now structured: = plone.uuid = plone.uuid provides a simple API for generating and accessing UUIDs. The principal API is the IUUID() adapter factory, which can be used to return a (byte string) UUID. There is also an IUUIDGenerator utility to generate new UUIDs. The default implementation uses the standard library uuid.uuid1() method. plone.uuid provides a marker interface IUUIDAware. Objects with this marker are expected to be adaptable to IUUID. There is an @@uuid view which renders a UUID string for an IUUIDAware object. This is useful in TAL, for example. plone.uuid also provides a specialisation of IUUIDAware called IAttributeUUID. Types that provide this interface get an IObjectCreatedEvent handler that generates and assigns a UUID stored in an attribute on the object, plus an IUUID adapter that looks up this attribute. = plone.app.uuid = plone.app.uuid provides some Plone policy for UUIDs. It contains a catalog indexer (using plone.indexer) for IUUIDAware objects, using the IUUID adapter factory. The indexer name is "UID", to be compatible with the existing UID index/metadata. Therefore, there is (no longer) a separate catalog setup step, and no migration required for existing Archetypes based content. plone.app.uuid also provides a view, @@redirect-to-uuid, which can be passed a UUID on the traversal subpath. This is then looked up in the catalog, before a redirect response is sent to the object's current location. There are also some utility functions to find objects by UUID in various ways. = Archetypes = The branch of Products.Archetypes makes Archetypes use plone.uuid to generate its UUIDs. The net effect is that the plone.uuid and plone.app.uuid APIs work for all Archetypes content (without migration), but can also be made to work with other objects. Archetypes objects are marked with IUUIDAware (but not IAttributeUUID). This makes the indexer, and @@uuid and @@redirect-to-uuid views work. UUIDs are still stored (in the _at_uid attribute) and created (by voodoo-wielding elves) in the same way as before. The make_uuid() function, which generates new UUIDs, now delegates to the IUUIDGenerator utility[1]. There is no migration for old content, but there isn't any need: UUIDs are still strings, and can't collide, even though technically new content will use a different algorithm. I did some tests TTW with references created "before" and "after", and they worked fine. There is an IUUID adapter factory for IReferenceable (which covers all Archetypes objects and, insanely, reference objects[2]). This returns the Archetypes UUID as stored in the _at_uid attribute, just as the UID() method used to do. The UID() method now does "return IUUID(self, None)". This means that if someone wanted to implement a custom IUUID adapter, the UID() method would follow suit. In theory, we could probably deprecate context.UID() metod in favour of IUUID(context) (in Python code) and context/@@uuid (in TAL), but I'm not sure we'd want to. It's used quite a lot. The plone.uuid way is more broadly compatible, though. = Dexterity et. al. = This isn't really part of the PLIP, but if the PLIP is accepted, I'll add plone.uuid support for Dexterity objects. That'll be pretty easy: just mark them with IAttributeUUID. We probably also want a migration step that grants UUIDs to and re-catalogs old Dexterity content. Presuming David finishes his work on plone.outputtransforms, this means link-by-uid to Dexterity content becomes a reality. We can maybe also make the standard reference browser widget work for non-AT content. UUIDs also become a viable thing to store for portlets and tiles that want to reference content. I also think we should consider adding UUIDs to comments if the plone.app.discussion PLIP is accepted. Cheers, Martin [1] I also took the opportunity to remove some weird, unused code attempting to use a Linux kernel UUID generator in /proc. [2] Whoever though people would *really* need references to references deserves to be locked in a room with Jeremy Beadle for two days ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
