Of course, separating data & logic is a meaningful thing in most scenarios, but that does not answer my current questions.
Ok, to be a bit more constructive some minds on sync from my side... If we speak about distribution on file level (in the cloud) the question is if it's neccessary to do that separation of data & logic on file level as well. One would think so. But I like the 1 file approach of tw5 very much and would not like to give it up if it's not really neccessary - it makes things very handy at all. If somebody would ask me for a blueprint of file level syncing of TW5 in a efficient but also simple way I would suggest the following: - keep things simple with the single file approach - over disadvantages it has many advantages - on sync side A: -- use the TW5 autosave capabilities to do not a save but an export of a file (call it syncStatusA) that has the following contents --- the logic to say what has changed (tiddler updated) --- the data that changed (tiddler data) -- the exported file will be automatically synced (if thats possible) by the cloud service client you are using (it's possible in mine) - on sync side B: -- use the TW5 autosave logic to do an import (read) instead of an export (if that's possible???) -- look for a exported file that has also been synced in the current file space (the syncStatusA file) and import it -- maybe a file naming convention for the syncStatus file is neccessary & sufficient here, but a property inside tiddlywiki describing the exact name of the import file for the current session would do it - if you don't want to think about the implications by working with both wikis on sides A & B on one and the same syncStatus file, then you have to choose a different name for the import and the export file of one wiki - or respectively, choose a different name of the syncStatus import/export file on both sides A & B - then you have a handshake, don't you?! - naming the import & export file different would be meaningful to make the sync robust for the unknown conditions of the cloud service (sometimes there's automatic file versioning, etc.) - so finally, the names of the files could be syncStatusA and syncStatusB and they would be synced by the cloud service and carry the information and data what has changed and will be imported automatically - and with minimal manual interaction of an handshake for a session you could have a synced tw5 - a session would mean here that you start with a synced wiki (copies) and do handshakes by determining the name (convention) of the syncStatus file considering the current cloud conditions - after the sync the syncfile of A has to be deleted by B and A is not allowed to write a new syncfile while the old syncfile exists -- that would work for a little number (10?) of team members, at least for 2, wouldn't it? - if you are more than 2 - say 10 - and you need for technical tw reasons not the naming convention but the exact name of the syncStatus file, then you would need the possibility to tell your tw not only one import/export naming convention of the syncfile, but 10 - in this case after updating a tiddler on side A nine (9) syncfiles will be created for the team members - so sync should be possible this way for small teams and I think you could put that functionality into a plugin - this would keep things quite handy for a 3 person team and would be a large benefit in workflow Perhaps Jeremy has a another comment on that? Regards, NT -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/tiddlywiki. For more options, visit https://groups.google.com/d/optout.
