Hi Arlen, Ah, definitely you clarify some unknow answers. Tiddlyweb is client oriented while filesystem is server oriented.
Le mercredi 21 août 2019 00:31:34 UTC+5:30, Arlen Beiler a écrit : > > To understand sync adaptors, you should look through these two plugins, > which contain the two sync adaptors used in the official data folder based > server edition (using the listen command). > > This one is loaded in the client and saves changes back to the server. > > https://github.com/Jermolene/TiddlyWiki5/tree/master/plugins/tiddlywiki/tiddlyweb > > This one is loaded on the server and saves changes to the filesystem. > > https://github.com/Jermolene/TiddlyWiki5/tree/master/plugins/tiddlywiki/filesystem > > In addition, here is the module that calls the sync adaptors to get > everything done. > https://github.com/Jermolene/TiddlyWiki5/blob/master/core/modules/syncer.js > > With a little bit of fiddling I managed to get the filesystem plugin > working in Electron so that it saved browser changes directly to the > filesystem without going through any kind of NodeJS server instance, but > that's a side note. For anyone else reading this who is curious, it > actually did save changes directly from the browser instance. I didn't load > the server listener or go through any kind of intermediary at all. It > required some modifications to boot.js though to correctly detect that a > datafolder was being loaded into the browser! > This is a nice behaviour. Jeremy could you comments Arlen's work. Standalone wiki with a local autosave is great. Thanks. > > Hope that helps. > > On Tue, Aug 20, 2019 at 2:51 PM Arlen Beiler <[email protected] > <javascript:>> wrote: > >> To load tiddlers on startup you can use the preloadTiddlers array. >> >> 1. Put this code in a head script: $tw = { boot: { suppressBoot: true }, >> preloadTiddlers: [] }; >> 2. Query the server for the user's tiddlers and handle the response >> asyncly when it is recieved (good for performance). >> 3. Wait for the window load event, which indicates that all code is >> initialized. >> 4. Push the JSON tiddlers (as field hashmaps) to the preloadTiddlers >> array. >> 5. Call $tw.boot.boot(); >> >> Tiddlywiki doesn't know the difference between this and a single-file >> wiki. It works the same in the browser once you call $tw.boot.boot(); >> >> On Tue, Aug 20, 2019 at 10:34 AM Jeremy Ruston <[email protected] >> <javascript:>> wrote: >> >>> Hi Xavier >>> >>> If I understand correctly. The save button call a saver (are the savers >>> chained in case of multiple setup, eg gitub, gitlab...? ) while the >>> syncadaptor is dynamic and reacts to events ? If its correct I like the >>> mechanism as it gives users a way to easily backup their wikis. >>> >>> >>> That's correct. The other thing to bear in mind is that the saver >>> mechanism can also be used to export any data as a file, it's not >>> restricted to saving the wiki itself. >>> >>> I'm not sure to understand here. I think this is why I'm lost. While >>> studying the syncadaptor I didn't get any understanding about how the >>> remote stored wiki has been initialized in the first place and this is why >>> I was thinking about my described mechanism. Load a self contained wiki. >>> Setup the ipfs target and then use the syncadaptor to push the contents to >>> IPFS. >>> >>> >>> In the case of the standard client server configution, the browser >>> connects to the default route triggering a build of the entire wiki file: >>> >>> >>> https://github.com/Jermolene/TiddlyWiki5/blob/master/core/modules/server/routes/get-index.js >>> >>> Another alternative is to start with an empty index.html stored anywhere >>> accessible via HTTP and have it interrogate the server for tiddlers when it >>> starts up. >>> >>> I think this is where I'm going to start. Define a saver and save the >>> whole content. I was too ambitious to jump right away on a SyncAdaptor. >>> There is always a learning curve... >>> >>> >>> Indeed, the saver mechanism is conceptually much simpler. It's also >>> likely to perform better in many situations as one large HTTP transaction >>> is generally faster than lots of little ones. >>> >>> I was following my idea. All the syncadaptors I studied assume that the >>> content is already on a remote server and I didn't see how the content has >>> been built in the first place. You explained earlier the external build >>> process but I still don't understand how the first load is working. If I >>> follow your mind It means that let's say you offer your user to start from >>> a set of wiki templates. Those templates are already built by an external >>> process. I was thinking like described. Load a plain wiki, install the >>> plugin, setup the plugin then sync to IPFS. The property was meant to >>> detect whether or not this wiki is already synced. I was looking to some >>> index technics but I didn't figure out yet how to get and process the store >>> list. >>> >>> >>> The core client-server implementation uses etags to keep track of >>> whether a particular tiddler has changed. >>> >>> Not sure to understand what you mean by updated. I'm targeting a single >>> user model. The only updates should come from the user actions. (updated >>> tiddlers, removed tiddlers,etc...) >>> >>> >>> That will certainly simplify things. >>> >>> Many thanks for your great work. >>> >>> Warmly. >>> >>> >>> Thank you for your interest, IPFS is really very cool and I'm delighted >>> to see you experiment with it, >>> >>> Best wishes >>> >>> Jeremy >>> >>> >>> >>>> >>>> -- >>>> 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 [email protected]. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/tiddlywikidev/004560cd-7acf-4408-a3b2-63e049db291a%40googlegroups.com >>>> >>>> <https://groups.google.com/d/msgid/tiddlywikidev/004560cd-7acf-4408-a3b2-63e049db291a%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>>> -- >>> 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 [email protected] <javascript:>. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/tiddlywikidev/b59dab66-8c82-4739-acd2-cc2a714f5e5f%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/tiddlywikidev/b59dab66-8c82-4739-acd2-cc2a714f5e5f%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >>> -- >>> 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 [email protected] <javascript:>. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/tiddlywikidev/65046341-255B-45EB-91BF-D4FB4F905892%40gmail.com >>> >>> <https://groups.google.com/d/msgid/tiddlywikidev/65046341-255B-45EB-91BF-D4FB4F905892%40gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/2f3409a9-1851-44d6-95e7-b4262b02448d%40googlegroups.com.
