Can we sync "delete" event after client reloaded

[linonetwo]

As I can read in the TiddlyWebAdaptor.prototype.deleteTiddler, it will be called by DeleteTiddlerTask, which is stored in Syncer.prototype.processTaskQueue, which is in JS's memory.

So if an HTML wiki using a sync adaptor connect with a nodejs server, is then saved as an HTML file, this deletion task is not persisted.

After this HTML file is reloaded in the mobile browser, the deleted tiddler will not keep deleted, it will comeback (I haven't tested this), is this true? We may need to store all these tasks, so sync adaptor works properly on deletion or rename.

Context:

I'm writing a custom syncer to sync between HTML wiki and nodejs wiki in https://github.com/tiddly-gittly/tw-mobile-sync

[Jermolene]

Hi @linonetwo you are correct. I think the commonest solution to this problem would be to maintain a "delete marker" tiddler for tiddlers that have been deleted. The marker would be a special tiddler that marks the tiddler as having been deleted. The marker would be synced just like an ordinary tiddler, but would behave like a shadow tiddler and not appear in lists etc. We may be able to store these delete markers as subtiddlers in a special $:/Deleted tiddler to give us the behaviour of shadow tiddlers.

I note that I think this could all be done in wikitext, by providing an alternate delete button that performs the required logic.

[linonetwo]

We can just add these logic to current delete button, why adding an alternate delete button?
Also, rename logic need this too, unless rename just call the delete logic.

But there can be a setting to toggle the behavior.

In most cases, there won't need these markers (fs sync adaptor that will immediately complete the delete task).

Some web related syncAdaptor will need this. I think i need to modify js code to do so, not only wikitext. So if the callback throw error, then marker tiddler remains, if succeed, then (real)delete the marker tiddler.

We may need to separate the try-delete logic with the real-delete logic.

[Jermolene]

We can just add these logic to current delete button, why adding an alternate delete button? Also, rename logic need this too, unless rename just call the delete logic.

I was thinking of approaches that could be implemented now, as a plugin without core changes, to explore the technique.

But there can be a setting to toggle the behavior.

Once it is in the core then I'd be inclined to make it the default behaviour, and use it to build the ability to automatically redirect links to deleted/renamed tiddlers.

In most cases, there won't need these markers (fs sync adaptor that will immediately complete the delete task).

I was thinking of using delete markers all the time; they provide useful functionality to end users. With a bit of care, the implementation could grow into a locally stored revision history.

Some web related syncAdaptor will need this. I think i need to modify js code to do so, not only wikitext. So if the callback throw error, then marker tiddler remains, if succeed, then (real)delete the marker tiddler.

It may well be necessary to make JS changes to implement this in the core, given backwards compatibility.