This sounds like symbolic links vs hard links in file systems. If you change the name of the file that a symbolic link (or shortcut in Windows) points to, it breaks. If you change the name of a file that a hard link points to it doesn't break . The reason for this is that the hardlink doesn't point to the copy of the changable name of the file, it points to a common inode that the other file (with the name changed) points to also. So they are pointing to a common source.
This leads to a similar solution as in file systems. Maybe tiddlers need an abstraction later where the immutable tiddler is like an inode and all renameable tiddlers are just all-field-trancluded inode-tiddlers. You could assign a randomized name to the immutable tiddler but if you want to go further, the names of the inode tiddlers can be a content hash ... maybe a SHA-1 of the tiddler contents ... so if the tiddler content changes, you can relink the hardlink-tiddlers to the new contenthash-tiddler. Then if you want to set up a permalink, it will use the contenthash-tiddler name. Then you can be guaranteed that the *permalink* is actually to the *content* that was originally linked ... if it still exists ... and not just to a ephemeral name. But this is actually sounding a little bit like git. It does offer some pretty lightweight revision tracking possibilities though. I don't think setting up a "redirect" is too tough though depending on the scope ... it is essentially just opening up the tiddler you want to rename, ctrl-A, ctrl-E, put in a new name and pick transclusion or macro ... although the other non-text fields wouldn't get excised+transcluded. Maybe there is a need for a "_content" field that acts like a _canonical_URI field but local to the tiddlywiki and replaces all the fields in the hardlink-tiddler with that of the tidder in the "_content" field. Maybe this is crazy-talk. /Mike On Wednesday, May 5, 2021 at 6:51:28 AM UTC-3 TiddlyTweeter wrote: > Ciao walt, > > Right. Tiddler PERMALINK-ability posted as URLs elsewhere is intimately > tied to NOT changing Titles. > > Personally I can't get in a hot sweat over that. That is no different than > any other web page. > SURE you could get into REDIRECTS on a server or up the complexity within > TW of self-REDIRECTS I guess? > > I don't really see the point though :-). > > Best wishes > TT > > On Wednesday, 5 May 2021 at 10:34:24 UTC+2 ludwa6 wrote: > >> The more i use TW, the more concerned i become about maintaining data >> integrity -and so this issue has boiled to the top of my queue: how can i >> continue to enjoy the benefits of TW (+ Relink plugin) flexibility, without >> compromising the integrity of Permalinks? >> >> This feels like a deep problem that goes right to core TW architecture- >> since, as PMario explained in last thread >> <https://groups.google.com/g/tiddlywiki/c/kTrAbuneCkA/m/lAsdkriFAgAJ>, >> tiddler immutability is tied to its Title (so how can Relink even work, i >> wonder?)- but if i've learned anything here, it is to not underestimate the >> creative problem-solving ability of this group :-)... SO: >> >> From a non-technical perspective, what i'd like to do is have some >> immutable UID (based on date-time, or maybe date+ a serial number, like >> yyyy-mm-dd-serialnum) that is used for Permalinks (i.e. shared w/ the >> outside web that is not Relink-aware), but still have Title field and >> Relink plugin (and everything else for that matter) work just as it does >> now, from the TW editor's perspective. >> >> Is this a reasonable feature design goal, i wonder? If so, i'd like to >> do what i can to help make it happen! >> >> /walt >> >> -- You received this message because you are subscribed to the Google Groups "TiddlyWiki" group. To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/3221e6e6-1771-4313-a2ae-09040e919c26n%40googlegroups.com.
