-
Notifications
You must be signed in to change notification settings - Fork 9
Roadmap
- Bag & Recipe system for storing tiddlers.
- User and Role management with ACL.
- Attachment system for storing binary tiddlers on the file system.
- Various import and export commands (currently still in development).
- AuthJS or a similar integration that supports third-party OAuth (you can already write your own).
- Compiling filters to SQL to optimize memory on both the client and server.
- Support for other database and storage systems. Most likely MariaDB and Postgres.
- Additional recipe strategies with features like prefixed bags and namespaces.
- Server rendering of pages, for a more wikipedia-like experience.
- Some kind of plugin system which provides a level of server-side access into the request path
We need the MWS server to be as modular as possible. Obviously certain things, like the route implementations, are difficult to make modular. But various sections are much more self-contained, or interact with the rest of the codebase in a small, well-defined way, and these can be turned into pluggable services.
Server routes for various sections of the UI can be kept separate, so the recipe/bag manger, user manager, and actual wiki routes can be put in separate modules so that one of them can easily be rewritten without affecting the others.
All of them interact with the database via the prisma adapter, which can be modified to handle different databases. We should support mariadb, sqlite, and postgresql to cover the main ones. Making sure the prisma client covers all three is probably important. There may be small differences between the prisma client for different database types, although this will be reflected in the types, so we should be able to figure that out pretty easily.
The attachment store isn't something I've taken a close look at.
The tiddlywiki instance on the server might stay. It serves a purpose as a field serializer that I'm not sure how to handle otherwise. It might be a good idea to move field serialization to the client and just expect the client to send the server string fields. But fields are strings most of the time anyway. It's a little confusing, but obviously on the file system all fields start as strings. So maybe we don't need it for that either. At this point I don't think we actually need it for anything besides rendering the index wiki. That might be moved to the start command instead of being part of the mws runtime. But it's also used for various import and export commands which still need to be available on the cli. We could make loading optional, or unload it after commands have completed, or once mws-listen starts.