Arlen, I would think this a great idea. SQLite, MariaDB etc... could be used. I use a cpanel account on a hosting service and often jump in behind the scenes to manipulate databases. It would be quite easy to define additional databases with an sql script designed for Tiddlers or TiddlyWikis.
In the spirit of brainstorming.The vast majority of my ideas may be implemented in tiddlywiki itself with SQL only the underlying database. The ease of securing online hosting for SQL databases would be a big plus as it is less onerous than the lesser available databases like CouchDB. Of course in time it would be good if we can ensure an editor at a time, or multi-user access to such a tiddlywiki database but simple single edit (Multiple read/Public) user implementations would be valuable. I believe a lot of control can be designed into this at the tiddlywiki level, just using the database as storage, tiddler at a time. Backend database tools could also clone wikis etc... and if we could get such an implementation script into installatron, softaliciouse etc... more people would discover tiddlywiki. The ability to store tiddlers in a sql database could be handled more than one way. - Allow an online readlony hosted wiki to connect to a database and with the right credentials save changes to tiddlers in an sql database and reload them as needed somewhat like Browser local storage does. - Store all of the wiki in a database. Or perhaps with the javascript or core in a file to help launch the wiki. - I believe there is a possibility for users to easily install SQL DB's they can connect to locally (Device or LAN) and overcome the limitations of browser local storage with trusted persistent storage (We can possible find multiple OS installs for this). - One minimal tiddlywiki could be configured to connect to more than one database, but one at a time, so the user or designer selects which database they are using (Like CouchDB), thus each user could perhaps have their own version of a tiddlywiki. I think however we need to ensure that a full wiki single file wiki can still be exported and ideally one imported into a database. Perhaps we could generate an SQL script from a living tiddlywiki and run that in PHPAdmin to build the database, then such scripts could be generated for various editions. One big advantage with SQL is there will be new opportunities for integration with other systems. Other systems could submit tiddlers to the database or query the database to interact with tiddlywiki. This integration includes between tiddlywikis, eg same database different tables/wikis and some primitives to use the other wiks tiddlers. Since I have investigated the development of a community resource website I have fancied building a WordPress site and having tiddlers in one or more wiki tables but with the ability to access content from the wikis in WordPress and Visa Versa, such as plugin and macro code and more. This would allow us to build a meta community site that can handle all the different TiddlyWiki objects, plugins, macros, editions, documentation submissions and discussions and more. I have toyed with new post types that allow people to submit content such as a plugin via a custom wordpress post that can then be dropped on a wiki. Buy doing this we can categorize sort, file, discuss .... Making us of WordPresses multi-user and OpenID and Auth systems over multiple tiddlywiki resources. *I would be quite prepared to test, participate and feed back on any such project. To me this could be the mainstreaming of tiddlywiki.* Regards Tony On Friday, November 29, 2019 at 10:59:43 AM UTC+11, Arlen Beiler wrote: > > I have a radical proposal which would take data folders to the next level. > What if instead of the file system adapter we would write a new adapter to > use a database. We could use PouchDB, but I would vote for something much > more widespread like SQLite. We could also write it in a generic way that > makes it easy to use with the regular SQL databases. It would be easy to > build but I would want to make it robust enough to use in a wide array of > platforms. > > I have already worked with the tiddler loading code enough to be certain > it is self contained and can easily be made asynchronous to accommodate > this feature. Or the preload tiddlers feature can be used, but I think it’s > better to separate out the loaders as Jeremy has mentioned. > > Any thoughts on this or things I should keep in mind as I brainstorm? > > Arlen > -- You received this message because you are subscribed to the Google Groups "TiddlyWiki" 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/tiddlywiki/37c23496-e987-4ccf-939a-98177ccb01cf%40googlegroups.com.
