Most Node solutions that I am aware of are either request-based (AWS Lambda and Cloudfront Workers), or VM based. There's also Heroku, but it doesn't allow a persistent file system. However, the data storage structure is a more serious bottleneck for innovation, I believe, and once we have a working system, it's easier to move to the next step. The biggest thing I see is the unpredictable nature of the file system as a predictable per-tiddler storage system. While it is possible to load tiddlers from the file system, I feel like some of the inherent drawbacks in this system are preventing us from taking it to the next level.
Once we store tiddlers in a database, we can write an alternate server that just stores client tiddlers straight to the database without going through a $tw instance on the server. We'll still have use for the server to bootstrap this system, but once setup, it can be fairly self-contained. In that sense, perhaps taking the node server to the next level means becoming smarter about the common use cases and writing software that can handle them more efficiently. Not much has been done to make use of the server itself -- most of the Node-side innovation is in other commands. The server was recently rewritten to make it more flexible for server-based solutions, which is useful. But I'm seeing a lot of client-side solutions that don't need the server at all, except to store tiddlers and files. In one sense it feels like a bit of a departure from the major possibilities that the TiddlyWiki server presents. And for me that's a little sad because I read source code and the TiddlyWiki server has enormous potential to work along-side the TiddlyWiki client in the browser for various solutions. But the general use-cases do not need this type of functionality, and indeed are encumbered by it because I there is no good way to tell whether a particular data folder needs the server-side components or not. Right now I could write a server using the filesystem adapter as my spec that would serve data folders using Apache and PHP, but there is no good way to tell whether any particular data folder might require the server-side instance, so it has to be explicitly stated in some way, and for that we need to come up with a new data folder format. The data folder could be marked by the specific presence or absence of certain plugins or other tiddlywiki.info properties, in order to properly trigger an alternate format, but I think the best way would probably be simply to add a property to tiddlywiki.info like "clientOnly": true. This would allow existing data folders to be converted easily if the owner knows it is safe to do so. It's not hard to implement this system with the current data folders either, it just requires a similar amount of effort, which may be necessary anyway. So I guess that breaks this up into several parts. - First we need to "invent" client-only data folders and implement them. - Second, we need to attach a more robust storage system that isn't encumbered by the various file systems. This would allow us to implement multi-user and version control quite a bit easier. - Third, we need to implement this in PHP as an identical implementation. I know it's a lot, but that's my summary of the what I'm seeing with what we've discussed so far. Arlen On Fri, Nov 29, 2019 at 5:44 PM TonyM <anthony.mus...@gmail.com> wrote: > Cont... > > Sorry. Mobile gg can be a pain. > > I understand Jed has done a lot of on securing bob when internet facing. > > So what I am asking is if node where more common on hosting and safe to > open to the internet could we not focus on a smaller subset of technologies > with similar outcomes? > > Of course we value a diversity of solutions. > > -- > 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 tiddlywiki+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/tiddlywiki/e7fd7b93-d44d-4de2-bbe5-63492ce18501%40googlegroups.com > . > -- 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 tiddlywiki+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/CAJ1vdSS3Z4J5asgfhG82aHK6%2BwRxVwR-kpH%3DvBuea%3DnBD2uBdg%40mail.gmail.com.
