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. > > -- > 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/b59dab66-8c82-4739-acd2-cc2a714f5e5f%40googlegroups.com. -- 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/65046341-255B-45EB-91BF-D4FB4F905892%40gmail.com.
