Hi Florian -- Thanks for your message. Why the -1? Trying to understand the nature of your objection.
I should have clarified something in my previous message. The UUIDs are only used by ReferenceManager -- they are not exposed in the UI at all, and the public methods in ReferenceManager (e.g., getReferredBy) still return WikiPaths like they always have. Users won't see anything different, and they can still enter wiki names as they always have. Behind the scenes, the UUIDs are stored in the back-end JCR pages as wiki:referenceTo and wiki:refererredBy properties. Whenever the page is saved, we extract out the page names that are referenced (as we normally do), normalize the page name, figure out the UUIDs, and then stash the UUIDs. So, in case it wasn't clear -- this UUID stuff is all under the covers. Does that make you reconsider your -1? ;) Andrew On Sun, Mar 14, 2010 at 12:40 PM, Florian Holeczek <[email protected]> wrote: > Hi Andrew, > > we've known this issue for quite a long time already, haven't we? > I've been trying to put the focus on it several times (search the list > for normalization, page name, wiki name). Happy to see that this is > finally recognized as a real problem before 3.0 release :-) > > My opinion in short: Introducing and using UUIDs is certainly the > standard and well-proven way to solve such a problem in information > science. However, we're building a wiki server and the wiki way is using > wiki names as identifiers. My opinion was and is that we need to > normalize wiki names, which means to think about a mathematical function > (probably surjective) to map a given wiki name to one defined page. > Unfortunately, this may mean that we're breaking links by removing the > fuzzy logic we've been using up to now. > > So basically, a -1 from me for the UUID solution. > > Regards > Florian > > > Am 14.03.2010 16:29, schrieb Andrew Jaquith: >> All (and especially Janne) -- >> >> In digging into some of the remaining bugs clustered in >> PageRenamerTest, I was forced to confront what I'd coded up during the >> last re-write of ReferenceManager. Lots of the PageRenamerTests are >> still broken. The problem with page-renaming relates, I suspect, to a >> checkin Janne did previously that sought to handle case-sensitivity >> filesystem issues. To put it simply, the relationship between the wiki >> path (as stored in the JCRWikiPage ATTR_TITLE attribute) and the >> filesystem wasn't being dealt with gracefully by ReferenceManager. The >> bug was too complex to track down, and I didn't have the patience and >> time to do it. >> >> I don't mean to blame Janne for this -- not at all. It merely sheds >> light on the difficulty of keeping references when the identifiers are >> page names. When the page name changes, we have to jump through lots >> of hoops to keep the references intact. You can blame ME for that. It >> reminded me of the old saying "programmers will create the most >> complex things they can debug". >> >> In thinking this through a bit more, I thought it might be better if >> we stored references as UUIDs. This means (for example) that renaming >> is simple -- all we really need to just change the page text, rather >> than the reference "pointers". So, that's what I've been experimenting >> with. It seems to work really, really well, and the code is simpler. >> >> The only odd case we have to deal with is when we're referring to a >> page that hasn't been created yet. In that case, what I've chosen to >> do is create dummy pages in a separate JCR branch (part of the >> /jspwiki/wiki:references node tree). Then, when pages are added in >> ContentManager, we check FIRST to see if that page is in the >> "not-created" tree. If it is, we MOVE it to the pages tree and then >> save as normal. Deletions work in reverse: if the page has any inbound >> references, we move it back to the "not created" tree to ensure that >> references from live pages stay intact; otherwise we zorch the page as >> normal. >> >> The "not created" page tree, by the way, is also an example of >> something I'm calling a "page foundry" -- a place where future pages >> are born but not yet moved into production. I can imagine other >> foundries -- for example, a per-user foundry for drafts. Maybe >> "nursery" is a better metaphor, but you get the idea. >> >> Thoughts? The code isn't quite ready, but it is progressing nicely. We >> might as well fix it before the 3.0 release, right? >> >> Andrew >
