Hi Tony Sorry for picking this up so late.
> TiddlyWiki is in fact both the Front End Gui and the backend server in one. > In fact in some ways the server based implementations do in some ways > separate the front and back already, Bob does this even more so with messages > to the server. To be clear, if you run TW5 under Node.js as an HTTP server then there are two distinct instances of the same TW5 code, one running in the browser, and one running on the server. They speak to each other via HTTP, and of course Bob adds a websockets channel of communication. > > What if TiddlyWiki X (an imagined future version) took this a lot more > seriously? > > Imagine if every tiddlywiki could act as a back-end to any other tiddlywiki, > this would allow one tiddly wiki to store its tiddlers in one or more other > tiddlywikis. Or another TiddlyWiki may host more than one other TiddlyWiki's > tiddlers for it. This is already possible. There is a well defined API through which the browser instance talks to the server instance, and there's nothing stopping experimenting with the browser calling multiple serverside APIs, nor with the server instance of TW5 itself using the API to speak to another instance. > That is the front and backend functions could be sub/divided internally and > externally. I think we have already exactly that level of encapsulation between the two parts. > Some may immediately see the potential of this but here are a few examples; > We could add security (authentication) the the connections to other wikis > rather than for each tiddler. If you have not authenticated you cant see the > tiddlers being served. The API does already support wiki-based security (it's enhanced in the latest v5.1.18). I've no current plans to explore tiddler-based authentication, but it remains open to investigation by others. > Maybe every tiddler is owned by a wiki and only it can change that tiddler > however the owner can pass ownership to another wiki. If designed correctly > the ownership could be passed back. The receiving wiki could choose if it > wants to accept or reject the tiddler. This may be different if its a macro, > plugin or style-sheet. That's pretty much how the API works: tiddlers get synced back to the server that they came from. > Otherwise a wiki can ask another to store its tiddlers for it, either with an > encryption key or without thus permitting access or denial of access of the > tiddlers by the containing wiki. That would be an enhancement to the API as things stand. As it happens I try to keep encryption and security components outside TW5 so that it is possible to re-use proven, off-the-shelf implementations, but it's still an interesting area to explore. > Containing wikis can consolidate tiddlers from multiple wikis, and display > them as well. > A wiki can choose to use an external wikis tiddlers through a pseudo import > process and the external wiki owns and can update them if permitted. > One TiddlyWiki may host tiddlers on behalf of another wiki through an > encrypted exchange, but may even host tiddlers in an encrypted form such that > the server Wiki cant even look inside the tiddler, just serve them. > Other front ends could be designed to interrogate the tiddler server, like > display a single tiddler content etc... These are the sort of features that could be implemented by the server side instance of TW5 invoking the API to talk to a different server. > In this model there would be no contention for tiddlers, as the ownership > exchange process handles this however we could pass a tiddlers ownership to a > server, which can be set up to respond with actions to transform the tiddler > and return it or another back to the original owner. Yes, this is exactly the sort of thing that would be interesting to explore. As I say, none of this is really about TWX. TWX is about revisiting design decisions that are too late to change in TW5. The classic example is that in TWX I want to explore a slightly different data model for tiddlers that unifies singleton fields with list fields. There's no way we can change something as fundamental in the context of TW5. But there's lots of other interesting experiments that can be done with TW5: we can literally take it apart and rebuild it into multiple different things (as the recent work on externalising the JS showed). Best wishes Jeremy > > Regards > Tony > -- > You received this message because you are subscribed to the Google Groups > "TiddlyWikiDev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to tiddlywikidev+unsubscr...@googlegroups.com. > To post to this group, send email to tiddlywikidev@googlegroups.com. > Visit this group at https://groups.google.com/group/tiddlywikidev. > To view this discussion on the web visit > https://groups.google.com/d/msgid/tiddlywikidev/712f0a17-f1d4-4c94-8ddc-9789ab6593dd%40googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group. To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywikidev+unsubscr...@googlegroups.com. To post to this group, send email to tiddlywikidev@googlegroups.com. Visit this group at https://groups.google.com/group/tiddlywikidev. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/2FC74FC2-12B8-421E-9ECB-83E11D220F85%40gmail.com. For more options, visit https://groups.google.com/d/optout.
