Jed et al Thanks for your critical analysis.
I do not disagree with you in any substantial way. If, as we do today, alternating the save mechanisium over different platforms, I believe it can be done, and in fact I belive this idea in part stems from inspiration from bob. Bob offers an even tighter solution allowing shared tiddlers without a wiki owning tiddlers. A network of wikis on top of node or bob offers a very powerful solution to share and federate, yet I like you, value maintaining the single file model indefinatly. It seems to me permitting node, bob and nodejs to also manage the sharing of tiddlers as in my suggested model, effectivly at a logicaly higher level of abstraction, where tiddlers are owned, can be stored elsewhere, but whos ownership can be relinquished to another wiki and/or backend, as bob would do very well, would allow even more loosly coupled networks of wikis. As I pointed out one wiki can relinquish ownership to another which may transform it and return ownership to the first. In this model there should be no contention at all. Critical also is this interwiki connection can have security or encryption applied at the connection not per tiddler, because the ownership model will handle that. The abstraction that any wiki can be the front end and backend (a single file wiki) or have multiple back ends (tiddler stores) or conversly be a front end to multiple tiddler stores, which node and bob can already excel at, is in some ways at a higher logical level above the concerns you express. There is little doubt such a solution would demand some accomodation in the core, but this need only be the facility and the specific details can remain in a combination of savers, optional key plugins or other (external) server components such as node, couch and pouch currently do. What is needed is tiddlywiki to recognise ownership of its own tiddlers where ever they reside, and respect tiddlers it does not own (as read only). The conseptual leap that tiddlywiki has already taken to be a form of quine where its user interface is totaly tweekable would be extended into its very storage mechanisiums itself. Thus we can say a tiddlywiki can be front and back end and any combination there of. One mechanisium I belive we do not yet have is the ability to include a single tiddler in one tiddlywiki found in another tiddlywiki without it existing in the same node network. Bobs messaging could facilitate this but we also want such tiddlers to be available at any url, file or in an addressable wiki found elsewhere. These ideas come from expierience as a cross diciplinary solutions designer, whilst my skill set is wide, and deep in many places it depends on a team or community behind it. It needs others, specialists, experts and diverse inputs. I recognise our community or team is wider and deeper than any individual can ever be. It is this I dream of engaging, and it can only evolve from communication. I hope this makes the ideas I am trying to express clearer, and utlimately propel tiddlywiki into the stratosphere, where it is already headed whilst maintaining its place in the two worlds of developers and users. Few users will understand database models, transactions or contention but they could understand how tiddlers can be owned and shared. I love tiddlywikis current capabilities but also its potentials. 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/3781c83f-99d3-42be-bfbc-6383f8b13b60%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
