"Universal plugin for tiddlywiki backup service" [concept, discussions]

#1

1. feature-name

“Universal plugin for tiddlywiki backup service” [concept, discussions]

2. feature-description

  1. My idea is just to integrate these existing plugins into a single plugin that I call “universal backup tiddlywiki” or “ubt” or “tiddlywiki.backup” or “tiddlywiki.services” or “tiddlywiki-connector” or “tiddlywiki.connection” or “tiddlywiki.odbc”
  2. It will be an abstraction layer that turns on/off the plugins responsible for synchronizing remote services description-plugin
  3. For this to be possible, it will be necessary to connect all types of existing backup and backup control services as GitHub, Google Drive, Microsoft Access, SQLite, Firebase…

2.1 concept

2.1.1 concept 1

Diagrams.net, Rclone, Mysql Connector, ODBC…

2.1.2 concept 2

image

2.1.2.1 Image description

We can see in the image that we have different connections to different services to synchronize your data.

3. FAQ - Frequently Asked Questions

3.1 - Why this feature?

  1. Some software that has this feature https://app.diagrams.net/ , rclone etc. That is, there are already technological solutions that have this concept that I describe here
  2. This can make life easier for users and the community.
  3. My idea is to make tiddlywiki more commercially usable: my ideas are these: universal backup plugin, tiddlywiki redesign,
  4. This ensures reliability, integrity, interobility, stability of tiddlywiki
  5. It’s something that’s already been asked a lot in old and newer Tiddlywiki threads.

3.2 - What will be the license of this plugin?

MIT

3.3 - How will this plugin be implemented?

  1. So… this is just an interface, an abstract layer - my idea is that below this layer I use the plugins for what I need. In other words, I don’t know if the plugins they use are from third parties
  2. It will be written in javascript programming language (current version of ecmascript 2019 language)
  3. Perform tests on each access permission to third-party plugins in a unitary way

3.4 - Is safe?

  1. Yes and no… because… all services being used are from third-party plugins, however, if there is interest from developers, this may be “official”
  2. yes… because… license is MIT (open-source).

3.5 - This has already been implemented, done?

I’m thinking about this personal concept, I still don’t have any development ideas - but I’m creating the concept, documentation for it

3.6 - Is the plugin paid?

It’s not paid, just community support.

3.7 - Features?

  1. Multi sync: Google Drive, firebase , Dropbox, GitHub Server, WebDAV, Saving on Sharepoint Online\Onedrive
  2. Multi control version: git, file-backups, json
  3. Automatic Backup

3.9 - todo to… do or task description\status

  1. Create data abstraction layer ‘done’
  2. Create plugin ‘do’
  3. Create documentation plugin doing
  4. Discuss plugin concept/idea for tiddlywiki community doing
  5. Check negative or positive feedback received about the implementation of the tiddlywiki universal backup plugin
  6. Perform tests on each access permission to third-party plugins in a unitary way

4 - Requirements?

  1. Create plugin to manage access to third-party plugins
  2. Check access to third-party plugins
  3. Check third-party plugin permissions
  4. Alerts the user to access certain information that is required by the third-party plugin, such as username, email or password if this access permission is required.
  5. Check if the implemented plugin complies with the necessary technical specification
  6. The plugin will be written in the client-side javascript programming language and should only work in the latest browser.
  7. Perform tests on each access permission to third-party plugins in a unitary way

5. Deadline

I don’t have time to develop, so there’s no deadline. The deadline here is sporadic, that is, when I have time, I will implement it little by little.

6. References?

WebDAV for saving single file wiki
#2

I’m thinking about this personal concept, I still don’t have any development ideas - but I’m creating the concept, documentation for it

#3

Yeah, it sounds too good to be true to me :wink:

1 Like
#4

@twMat Hi! Thank you for feedback… so the plugins already exist and work, my idea is just to integrate these existing plugins into a single plugin that I call universal backup tiddlywiki - would this be a good idea?

#5

Well it sounds like a fantastic idea. I really do mean that “it sounds too good to be true” to me. If you didn’t see it, here is a gh thread that may be of interest to clarify some opinions and thoughts on the matter.

2 Likes
#6

I too think this is a good idea,

I will just add saving remains somewhat confusing to many people and I can’t yet see the details of implementing it. The thing is the saving or “download” may prove trivial, reopening a wiki so saved can be left to the user, but the ability to save back after that is where the question is.

Rather than “device” perhaps “local file/download”.

  • Perhaps
    • save the selection of the “save destination” in the wiki you download.
    • after downloading to one of these devices we provide more info on how to ensure they can open and autosave back for the method they chose. eg installing Timimi
2 Likes
#7

other reference: twdev Tiddlywiki + MS-Access, twdev Tiddlywiki + SQLite, concept: “Universal plugin for tiddlywiki backup service” is odbc”
add backup-services: hypercore, ipfs …

plugin.tiddlywiki.odbc:

  • Multi Sync: services(‘Google drive’, ‘SQLite’, ‘Microsoft Access’, ‘Firebase’, ‘Dropbox’, ‘GitHub’, ‘SharePoint\One drive’), protocols(‘Hypercore’, ‘IPFS’, ‘Webdav’)
  • Multi Control version: ‘git’, ‘file-backups’, ‘json’
  • Automatic backup
2. notes
  1. I’m thinking of naming this plugin as odbc - Open Database Connectivity - why? mysql has what they call odbc or connector - Here is the same idea with the difference it would be for backup data to different services/apps/providers/hosts/servers/client-protocols etc
  2. reference: What Is ODBC? - ODBC API Reference | Microsoft Docs
1 Like
#8

Some reflections

  • If it covers all those cases, will it be a huge plugin?
  • Could it be “modular” so the user can somehow select which savers he is interested in?
  • I hope the code will be transparent enough so that people know they can trust it :slight_smile:
  • You seem to be an experienced coder. Do you have a github page? Have you made any other plugins for TW?
2 Likes
#9

great idea… So… I was thinking of following this line of thought here:

var tiddlywiki_odbc = require('tiddlywiki_odbc');
var tiddlywiki_sync = new Google drive(["Hello, world!"], {type: "text/plain;charset=utf-8"});
tiddlywiki_odbc.syncWith(tiddlywiki_sync, "hello world.txt");

references

#10

use cases

  1. Google Drive
  2. Dropbox
  3. SQLite
  4. MicrosoftAccess
  5. Firebase
  6. GitHub
  7. SharePoint
  8. OneDrive
  9. Hypercore
  10. IPFS
  11. Web dav
#11

OK, I’m not a coder so I’m afraid this is above me but there are other coders here that will surely appreciate this clarification of yours.

Maybe this is exactly what your code answers but: Are the savers “direct” or do they go via some kind of third party service, i.e other than the final saving service (e.g dropbox)?

1 Like
#12

This is just an interface, an abstract layer - my idea is that below this layer I use the plugins for what I need. In other words, I don’t know if the plugins they use are from third parties

#13

Actually, this might be what we’ve been needing all along. For some reason, almost all savers are about saving to the local computer. Not all of them but most, at least as far as I understand. But everyone obviously has cloud storage so I would guess most people would rather save on the cloud these days. (But I must admit that I didn’t try the majority of the existing TW savers, so maybe I’ve misunderstood).

You’ve really raised my hopes :grinning_face_with_smiling_eyes:

Another interesting aspect; I wonder if there are check-in check-out features in any of these storage services that would somehow enable multi-use of a TW… hmm… Again, I know very little of this so maybe I’m just talking nonsense…

2 Likes
#14

I’m still thinking about it, for now I just wrote at the top what the data abstraction layer would look like.

#17

@twMat @TW_Tones Hi! How are you? Could you check this technical specification?

#18

From a user perspective, I can’t think of anything to object to or add. I guess it is just a matter of adding stuff if new questions arise. I have certainly never seen anyone specifying things like this in the TW community before - interesting to see, and probably useful if anyone jumps in with support at a later stage.

1 Like
#19

I cant for a few days unfortunately. I think this should start ate least with pointing to the documentation for the use of each method.

The initial save can be a download to each of these services but then they need to be available on the host device unless we can use some APIs to go directly, logging in if necessary.

Then each cloud or device needs the appropriate setup for automatic saving within the browser, and on each device that accesses it.

Finally if you access the same file on the same cloud drive a mechanism to stop one instance overwriting another is needed.

1 Like
#20

Hi @anon5541130 great stuff. I wondered if you’d seen remotestorage.io:

It’s very much along the lines you are exploring: a standardised interface for talking to a variety of back end cloud and local storage platforms. It has been around for about as long as TW5, and still seems to be busy and maintained.

3 Likes
#22

See related discussion from RS forum remoteStorage plugin for TiddlyWiki - #3 by stokito - App announcements - remoteStorage Forums

#23

Regarding TW + SQLite, in TiddlyWikiPharo we have been combining TW with Fossil SCM, the distributed control version system powered and used by SQLite. For this, we export, inside TiddlyWikiPharo, the tiddlers from JSON to STON , which is diff friendlier and extensible and then we save all tiddlers in Fossil. The combination is orchestrated from a data narrative written in Pharo / Lepiter (which is kind of the recently arrived equivalent of Jupyter notebooks in the Pharo world).

Combining TW, Pharo and Fossil gives us autonomous scalability and agile extensibility without going with data oligopolies.

As your project advances, we could learn how you implemented the storage backeds.

Thanks for your conceptual prototypes and keep us posted about your advances.