Replies: 4 comments 13 replies
-
|
That's interesting, but without seeing anything it's hard to give feedback. What's about the pricing? |
Beta Was this translation helpful? Give feedback.
-
|
I also think the "fee tier" is per account, so it has to be shared by all wikis. -- right? |
Beta Was this translation helpful? Give feedback.
-
|
These details are very helpful, because they'll enable us to work out what needs to be modified to make it work, thanks! From a TW5 perspective, my plugin uses the existing sync mechanism, with all of its current design decisions. For example, a common bug in the current sync mechanism is that it fails to do the last write, so the very last thing the user did is never written to the store, usually just one character or a fragment of a word at my typing speed. System tiddler syncing is off by default, but I wish to turn it on because without it you cannot install additional plugins in a meaningful way. When you say the default syncer polls the whole store every minute, what does that mean exactly? I have not seen this behaviour in my plugin, but I may not be paying enough attention. Does it ask the plugin to read every document every minute? It's this kind of usage - not tied to user behaviour - that will ultimately be most problematic for the free tier. I completely agree that users will just leave tabs open, potentially multiple tabs on the same computer, 24/7/365, and that can become a problem. The free tier is per Google Cloud project. When the user uses the meta project to create their wiki, it makes a new cloud project, so each wiki is in a new free tier. The user can run out of Google Cloud projects relatively easily if they create dozens of wikis, but until they do each one gets a new free tier to play in, and each one is separate (that is one could go quota exceeded while the others work fine). Sorry for the delay posting a link; I will get a link to the deployed meta project up once the UI has a little feedback on what's going on. Provisioning the cloud project takes time and in testing it with new accounts I found that if the user has never accepted Firebase's terms of service it doesn't work. I need to fix these problems before putting up a link you can try. |
Beta Was this translation helpful? Give feedback.
-
There is a GET command that is automatically triggered by the client every minute. See the screen-shot F12 - Network tab
Request - Skinny tiddlers
Response
|
Beta Was this translation helpful? Give feedback.
-
That's good to know |
Beta Was this translation helpful? Give feedback.
-
No problem. Take your time |
Beta Was this translation helpful? Give feedback.
-
|
In the edition I am running, which is 
Here is a URL at which you can try it out: https://tiddlywiki-a94cd.web.app/ If you're concerned about the OAuth token being obtained, which allows my code to manipulate your google cloud state for up to 1h after you sign in, make a new Google account to try it out with. If you make a new google account (or if you've never used firebase before) a defect in the current implementation is that it can't accept the terms of service for you or take you through a ToS flow, so you have to go create a throwaway firebase project on the usual console first, and then come back and click the create wiki button. Additionally, if you use a throwaway account you can be sure Google cannot bill you no matter what bugs might be present in my implementation or in TW5 itself, so it's a nice way to have a playground to look at the project in. Once you've created your wiki, if you share it iwth me (anicolao) using my gmail.com as my email address, I will be able to see it and collaborate on your tiddlywiki with you. |
Beta Was this translation helpful? Give feedback.
-
|
Are you talking about syncer or sync-adaptor? With sync-adaptor you won't need to
You can just save what is changed. See #7720 |
Beta Was this translation helpful? Give feedback.
-
|
The plugin is a sync adaptor. It doesn't save redundantly. But the intention is to save everything (once) so that your entire wiki is in your firestore storage, and when you reload it from a new device you're exactly where you left off. |
Beta Was this translation helpful? Give feedback.
-
|
Cool, So you store all tiddlers as rows in database, and when open webpage again later, you can lazy-load then? I was trying to do this with SoLiD in https://github.com/linonetwo/solid-tiddlywiki-syncadaptor , but I was not so familiar with tiddlywiki at that time. I can learn from your code to upgrade the solid syncadaptor. |
Beta Was this translation helpful? Give feedback.
-
|
My (very early version) sync plugin code is here: https://github.com/anicolao/tw5-firestore-sync It doesn't lazy load; on startup it will read all tiddlers into memory. After that, it reads and writes only changed tiddlers. With firebase it is easy to enable local caching (which I have not done yet) so that the startup load comes from indexeddb on the client instead of over the network, so this should be fast enough even for largish wikis. |
Beta Was this translation helpful? Give feedback.
-
|
Maybe it is hard for me to access firebase in my region? It just stop here. |
Beta Was this translation helpful? Give feedback.
-
|
Sorry I need to improve the error handling. This is because you've -never- created a firebase project before. As the text at the top of the pge says, if you've never used firebase you have to go to the firebase console and create any project to agree to the terms of service. Then you can delete that project or just leave it there, and come back - the 'adding firebase' will then succeed. Until you've aaccepted the terms of service, it gets stuck here. Please do try again! |
Beta Was this translation helpful? Give feedback.
-
|
In the firebase console, once you reach a page like the one shown below for your new project, coming back and trying again should work. |
Beta Was this translation helpful? Give feedback.
-
I looked at the existing firestore plugin and it wasn't at all what I wanted, so I wrote what I wanted.
This has resulted in a very early proof of concept and I would welcome feedback here on where to take it / what features people would like to see. The project does not involve modifying TiddlyWiki5, but is built to work with the existing system.
There are two parts to the project:
A firestore sync plugin, that uses the existing sync mechanism to save all your tiddlers to a firestore database bi-directionally. The effect of this on a vanilla tw5 empty instance is that all viewers of that instance see the same state: the same story river, the same tiddlers, the same drafts. They can even attempt to "collaboratively" edit a draft, though the delays implemented in the core for how this works make the experience a little janky. Nonetheless it is a "multi-user" wiki where all users see and edit the same state simultaneously.
A meta website which lets you click a button to generate a new URL configured to point at a firestore backend that you own. This works by asking you permission to modify your google cloud projects, creating a project named tw5-yourwikiname-randomdigits, creating a firestore database in it for you, configuring security rules on your backend database, and then serving your URL so that when you click the link to open your wiki you are now looking at your content on your backend.
From here, many different directions could be pursued. The wikis could be sharable, with multi-user collaboration and editing; the wikis could be entirely private; it might be nice to have collaborative editing working smoothly in the wikis; etc, etc.
I am very keen for feedback/input if this sounds interesting to others.
Beta Was this translation helpful? Give feedback.
All reactions