And again all thanks for the continuing input, carefully considered feedback is very valuable and your efforts are recognised.
It seems to me we are getting close to a first use "ease of use" then making tiddlywiki your own, basically save back to a tiddlywiki on your own drive. I hope we can finalise this. I see some wandering into the broader savings issues such as cross device, consolidated servers which is ok but in some ways it is the next step. Using the Bob file saver plugin with bob.exe for example is already introducing server services However the key initial reason for bob.exe in my view is the possibility of a simple adoption process. >From my original topic, I am really keen to refine the first engagement steps >because I believe this can and must be simplified to not just support new >users but support designers publishing work to general audiences (starting >with read only html publishing). It is my view while we should keep in mind more sophisticated implementations like server, cross device, multi access and multi user etc. . the next critical step in my view is controlled editing. The first being serial editing especially starting with single file wikis but later extending this to authorised editing. Serial editing Single file wikis typically save the whole wiki into a single file so two similtaniouse edits users or tabs, will overwrite one set of changes with the other. To enable serial editing to stop this potential loss we need to introduce a login/out mechanisium in single file wikis or check-in or checkout. This is to handle the case where more than one user has update/save rights. I have researched this deeply. And will not detail it here but the trick is to reload a wiki with a checkout request in uri or temp storage and save the wiki with the checkout details only if sucessful, perhaps with another reload to confirm the checkout. This may be prohibitive on large wikis so a wrapper wiki to control edit of another wiki may be needed. This type of mechanisium will also support the use of multi device via cloud shares, overwrite protection on tiddlyserver, node, tiddlydesktop and more. Bob already has some protection. Check in and out in single files would open the smart document possibilities by permitting edit control and multi user (serial) to take place in documents that are sent around physically or functionaly to multiple users. A concept I like is the idea of documents with a document management system built in. Your thoughts please Is serial edits the next step as I believe? Are there other ways to achieve this? yours sincerely Tony -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/b8820717-e260-4d4b-9736-752c432cb072%40googlegroups.com.
