On 6/14/06, Thorsten Scherler <[EMAIL PROTECTED]> wrote:
I think we should talk about blockers, resolve them and do a 1.4.1 release. I hope that many committer will review the 1.3 revolution and then we should start a 1.5 branch where we take the best from 1.3 and 1.4 and add all new features that are still missing 1.4.
1.3 uses UNIDs. The "New Resource" code has not been written yet, so any format is fine. The migration (from 1.2) routine is easy to change to any format. The UNIDs can be: Sequential numbers: 0001, 0002, 0003, etc. Padded to look pretty in a directory. This format is fine for the migration, but is a poor choice if Resources are created on multiple servers. UUIDs: Big long guaranteed unique numbers. Anything involving multiple servers should use them. (Domino mixes this with sequential numbering. Each datastore sequentially numbers the Resources in its own datastore, but assigns a UUID to uniquely identify each Resource when merging datastores.) IDs: Start with the ID assigned by the creator of the Resource. Add a suffix if it is not unique. Never change the UNID. Resource #1 ID="news" UNID="news" Resource #2 ID="news" UNID="news1" Change Resource #1's ID="oldnews", UNID is still "news". This has the multi-server issues of sequential numbering, and adds confusion when IDs are changed. Lenya1.3 can mix all formats, as long as each UNID is unique (and can be a directory name). My current plan is to keep the migration routine using the sequential numbers, but all new Resources are assigned a UUID as the UNID. 1.3 Vistors see hierarchical IDs, just like 1.2. Maintenance must be handled with UNIDs, since IDs are not unique. Even with the flat datastore, there could be a page with the hierarchical ID: news/news/news.html solprovider --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
