SyncAdaptor

[Xavier Maysonnave]

Hi All,

I'm quite new @ TiddlyWiki and I need some guidance.

I try to develop a new plugin to store tiddlers on IPFS.

I hardly studied a few SyncAdaptor implementation but I'm lost :

- https://github.com/wshallum/couchadaptor

- https://github.com/linonetwo/solid-tiddlywiki-syncadaptor

- https://github.com/fiatjaf/tiddlywiki-remotestorage

- https://github.com/bourgeoa/tiddlywiki-node-solid-server

Here is what I want to achieve :

- load a plain tiddlywiki (I'm planning to offer my users a set of predefined wikis, probably on IPFS but self-contained)

- the plugin is loaded but should be inert until the first save to the appropriate server. The first save should analyse the content and upload the content to IPFS.

Each tiddlers in a separate file, especially for external attached file. Maybe the first step is to have a self contained file ??

Question :

- how do I detect that the wiki is not fully IPFSified yet ? probably a property, but where ?)

- how to I bypass the SyncAdaptor (inert) during the first load ?

- It is not clear yet how savers and syncadaptors are processed :

Let's say that you setup a github account and you have also the IPFS syncadaptor.

Who's winning, the saver or the SyncAdaptor.

A lot of questions I agree. I hope that my questions make sense and are clear.

Thanks

[Jeremy Ruston]

Hi Xavier

I'm quite new @ TiddlyWiki and I need some guidance.

Welcome to the project!

I try to develop a new plugin to store tiddlers on IPFS.

I hardly studied a few SyncAdaptor implementation but I'm lost :

- https://github.com/wshallum/couchadaptor

- https://github.com/linonetwo/solid-tiddlywiki-syncadaptor

- https://github.com/fiatjaf/tiddlywiki-remotestorage

- https://github.com/bourgeoa/tiddlywiki-node-solid-server

Here is what I want to achieve :

- load a plain tiddlywiki (I'm planning to offer my users a set of predefined wikis, probably on IPFS but self-contained)

The general approach taken by the sync mechanism has two parts:

* A means to construct a TW5 HTML file from the constituent tiddler files

* A mechanism to sync individual tiddler changes from that HTML file back to the server

It is orthogonal to the saver mechanism which is concerned with saving the entire HTML file as a single file.

The two mechanisms are pretty much independent: one can be syncing individual tiddlers to a server and then simultaneously use the saver mechanism to save a snapshot of the entire wiki.

One crucial difference is that the syncer mechanism requires an external process to build the HTML file. That is done dynamically in the default client server configuration: the route `/` triggers a build of the entire wiki. It can also be done by an external build process that periodically rebuilds the HTML file.

- the plugin is loaded but should be inert until the first save to the appropriate server. The first save should analyse the content and upload the content to IPFS.

Each tiddlers in a separate file, especially for external attached file. Maybe the first step is to have a self contained file ??

IPFS is static storage so yes, I think it would be much easier to focus on the single file configuration.

Question :

- how do I detect that the wiki is not fully IPFSified yet ? probably a property, but where ?)

I'm not sure what you mean here?

- how to I bypass the SyncAdaptor (inert) during the first load ?

When it starts up, the sync adaptor should interrogate the server to obtain any tiddlers that have been updated since the HTML file was built.

- It is not clear yet how savers and syncadaptors are processed :

Let's say that you setup a github account and you have also the IPFS syncadaptor.

Who's winning, the saver or the SyncAdaptor.

A lot of questions I agree. I hope that my questions make sense and are clear.

Thanks

No problem, I hope my brief answers help, please don't hesitate to ask followups. These kinds of discussions can be helpful for observers, too.

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 tiddlywikide...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/004560cd-7acf-4408-a3b2-63e049db291a%40googlegroups.com.

[Xavier Maysonnave]

Hi Jeremy,

Thanks for your warm welcome.

Le mardi 20 août 2019 14:26:32 UTC+5:30, Jeremy Ruston a écrit :

Hi Xavier

I'm quite new @ TiddlyWiki and I need some guidance.

Welcome to the project!

I try to develop a new plugin to store tiddlers on IPFS.

I hardly studied a few SyncAdaptor implementation but I'm lost :

- https://github.com/wshallum/couchadaptor

- https://github.com/linonetwo/solid-tiddlywiki-syncadaptor

- https://github.com/fiatjaf/tiddlywiki-remotestorage

- https://github.com/bourgeoa/tiddlywiki-node-solid-server

Here is what I want to achieve :

- load a plain tiddlywiki (I'm planning to offer my users a set of predefined wikis, probably on IPFS but self-contained)

The general approach taken by the sync mechanism has two parts:

* A means to construct a TW5 HTML file from the constituent tiddler files

* A mechanism to sync individual tiddler changes from that HTML file back to the server

It is orthogonal to the saver mechanism which is concerned with saving the entire HTML file as a single file.

The two mechanisms are pretty much independent: one can be syncing individual tiddlers to a server and then simultaneously use the saver mechanism to save a snapshot of the entire wiki.

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.

 

One crucial difference is that the syncer mechanism requires an external process to build the HTML file. That is done dynamically in the default client server configuration: the route `/` triggers a build of the entire wiki. It can also be done by an external build process that periodically rebuilds the HTML file.

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.

 

- the plugin is loaded but should be inert until the first save to the appropriate server. The first save should analyse the content and upload the content to IPFS.

Each tiddlers in a separate file, especially for external attached file. Maybe the first step is to have a self contained file ??

IPFS is static storage so yes, I think it would be much easier to focus on the single file configuration.

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...

 

Question :

- how do I detect that the wiki is not fully IPFSified yet ? probably a property, but where ?)

I'm not sure what you mean here?

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.

 

- how to I bypass the SyncAdaptor (inert) during the first load ?

When it starts up, the sync adaptor should interrogate the server to obtain any tiddlers that have been updated since the HTML file was built.

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...) 

 

- It is not clear yet how savers and syncadaptors are processed :

Let's say that you setup a github account and you have also the IPFS syncadaptor.

Who's winning, the saver or the SyncAdaptor.

A lot of questions I agree. I hope that my questions make sense and are clear.

Thanks

No problem, I hope my brief answers help, please don't hesitate to ask followups. These kinds of discussions can be helpful for observers, too.

Best wishes

Jeremy

Many thanks for your great work.

Warmly.

 

--
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 tiddly...@googlegroups.com.

[PMario]

On Tuesday, August 20, 2019 at 11:35:29 AM UTC+2, Xavier Maysonnave wrote:

It is orthogonal to the saver mechanism which is concerned with saving the entire HTML file as a single file.

The two mechanisms are pretty much independent: one can be syncing individual tiddlers to a server and then simultaneously use the saver mechanism to save a snapshot of the entire wiki.

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.

Savers are _not_ chained at the moment. ... But they could and imo should be, if we would change the code accordingly.

 

One crucial difference is that the syncer mechanism requires an external process to build the HTML file. That is done dynamically in the default client server configuration: the route `/` triggers a build of the entire wiki. It can also be done by an external build process that periodically rebuilds the HTML file.

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.

It is possible to create a syncadaptor that can handle single file tiddlers, that works with IPFS if the browser can access the API needed.

I did create a proof of concept some time ago, with an outdated version of beaker-browser, which allows me to write to a DAT archive, with single file tiddlers.

have fun!

mario

[Jeremy Ruston]

> Savers are _not_ chained at the moment. ... But they could and imo should be, if we would change the code accordingly.

Savers are kept in a priority ordered list. When an attempt is made to execute a save, the savers are called in turn until one indicates that it has handled the save.

Best wishes

Jeremy

[Jeremy Ruston]

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...

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 tiddly...@googlegroups.com.
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 tiddlywikide...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/b59dab66-8c82-4739-acd2-cc2a714f5e5f%40googlegroups.com.

[Jeremy Ruston]

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 tiddly...@googlegroups.com.
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 tiddlywikide...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/b59dab66-8c82-4739-acd2-cc2a714f5e5f%40googlegroups.com.

[Arlen Beiler]

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();

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/65046341-255B-45EB-91BF-D4FB4F905892%40gmail.com.

[Arlen Beiler]

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!

Hope that helps. 

[Xavier Maysonnave]

Hi Mario,

Thanks for your feedback.

I noticed while googling this effort around beaker browser.

Let's see what happen. 

Hope to publish something on GitHub and gather some experts around it.

[Xavier Maysonnave]

Hi Jeremy,

1 - Interresting behaviour. 

Is there a way to influence the priority ordered list ?

You didn't comment Mario's clarification about chaining savers.

Is there any reason why savers are not chained ?

2 - I started to work on a saver.

I'll see the syncadaptor afteward.

Step by step :-)

Thanks

[Xavier Maysonnave]

Hi Jeremy,

Le mardi 20 août 2019 20:04:28 UTC+5:30, Jeremy Ruston a écrit :

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,

Thanks for your warm support. 

Looks to me that in its essence tiddlywiki is an early dapp. 

This is the reason why I experiment it. It could a be a very nice privacy serverless decentralized component.

Warmly

 

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 tiddly...@googlegroups.com.
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 tiddly...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/b59dab66-8c82-4739-acd2-cc2a714f5e5f%40googlegroups.com.

[Xavier Maysonnave]

Thanks Arlen,

I keep your idea on the margin when I'll go deeper.

Quite familiar with async call though.

However is there any benefits to handle tiddlers that way rather than using startup modules ?

Thanks

Hi Xavier

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 tiddly...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/65046341-255B-45EB-91BF-D4FB4F905892%40gmail.com.

[Xavier Maysonnave]

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. 

Hi Xavier

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 tiddly...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/65046341-255B-45EB-91BF-D4FB4F905892%40gmail.com.

[Arlen Beiler]

I think the main benefit of this over making a startup module to load the user's tiddlers is that it is far simpler. There is a core template which loads a separate cache-able Javascript file with the core code and plugins (instead of including it in the HTML page) which uses $tw.loadPluginsArray(). You can find the related templates here: https://github.com/Jermolene/TiddlyWiki5/tree/master/core/templates/external-js

To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywikide...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/0635867c-aab3-4067-847a-62b4c3a6ea8b%40googlegroups.com.

[PMario]

On Wednesday, August 21, 2019 at 6:03:43 AM UTC+2, Xavier Maysonnave wrote:

...

1 - Interresting behaviour. 

Is there a way to influence the priority ordered list ?

You didn't comment Mario's clarification about chaining savers.

 

The priority is hard-coded. The priorities are "grown" over time, based on demand.

Every saver implements a .canSave() function, which basically is a feature detection.

The first saver that can handle the save request does it :) ... This behaviour makes sure, to work for novice users, with "zero configuration". ... We want to create sensible defaults. So if a user uses TW with a dat:// enabled browser AND we have a saver it should "just work".

Is there any reason why savers are not chained ?

hmm, ... Nobody did create a backwards compatible PR ... yet ;)

 

2 - I started to work on a saver.

I'll see the syncadaptor afteward.

Step by step :-)

I think, that's the right way to go. savers are much simpler at the beginning.

-m

[Jeremy Ruston]

Is there any reason why savers are not chained ?

hmm, ... Nobody did create a backwards compatible PR ... yet ;)

What does "chained" mean in this context? The savers are already stored in a priority ordered list.

Best wishes

Jeremy

 

2 - I started to work on a saver.

I'll see the syncadaptor afteward.

Step by step :-)

I think, that's the right way to go. savers are much simpler at the beginning.

-m

--
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 tiddlywikide...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/4e18f2b7-8867-496f-8104-112d60ab208d%40googlegroups.com.

[PMario]

On Wednesday, August 21, 2019 at 6:16:26 AM UTC+2, Xavier Maysonnave wrote:

...

Tiddlyweb is client oriented while filesystem is server oriented.

That's right.

The tiddlyweb plugin has to be part of the client, if you want to save to a tiddlyweb compatible backend.

   syncer is a "client-side middelware", so you can use different adaptors. If no adaptor is active, savers are used.

filesystem plugin is part of the server and implements the basic file based "storage engine".

-m

[PMario]

On Thursday, August 22, 2019 at 10:22:43 AM UTC+2, Jeremy Ruston wrote:

Is there any reason why savers are not chained ?

hmm, ... Nobody did create a backwards compatible PR ... yet ;)

What does "chained" mean in this context? The savers are already stored in a priority ordered list.

... Yea, but if a saver saves the file, the action is stopped. ... It may be preferable for a user to activate several savers.

eg: The PUT saver can save to a webDav enabled server. Then it stops ... BUT a local backup saver would be a nice thing to have. ...

So 1 save action creates 2 different files.

-m

[Xavier Maysonnave]

Hi All,

1 - I found how priority are managed. 

Right now my saver is not called. 

Quite difficult to debug as the file is big (around 5Mo), Chromium is struggling. 

The code I would like to debug is also on one line...so a breakpoint is not exactly suitable...

2 - In this context (with a priority ordered list) nothing. As I didn't know how it was implemented I got some wrong expectations.

However I agree with Mario it could be nice as far as savers are elligible.

Many thanks guys for your advise and guidance.

Cheers

Le jeudi 22 août 2019 13:52:43 UTC+5:30, Jeremy Ruston a écrit :

Is there any reason why savers are not chained ?

hmm, ... Nobody did create a backwards compatible PR ... yet ;)

What does "chained" mean in this context? The savers are already stored in a priority ordered list.

Best wishes

Jeremy

 

2 - I started to work on a saver.

I'll see the syncadaptor afteward.

Step by step :-)

I think, that's the right way to go. savers are much simpler at the beginning.

-m

--
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 tiddly...@googlegroups.com.

[Xavier Maysonnave]

I found the proper way to debug. Nevermind...