Chris, the "small things, loosely connected" argument makes sense here, and as an aspiration, that's a sensible architecture. I think we can break down Web UIs for TiddlyWeb into 3 categories: * Client-driven - typically a Javascript web app, TiddlyWiki or otherwise, making RESTful calls. * External server-driven - Django, Rails, Java, whatever server making server-to-server calls to TiddlyWeb * Tiddlyweb-driven - A server somehow embedded in TiddlyWeb
While I appreciate the principle, I do think right now the third option is somewhat more appealing than the second option.
The main reason is that web frameworks like Django and Rails assume derive their considerable agility from making certain assumptions about the underlying persistence framework. The more you deviate from the typical case, the more these frameworks become cumbersome to deal with, and in unchartered ways.
There are probably plugins around that will deal with RESTful services in some way, but they won't be at all TiddlyWeb-specific. I can't, for instance, point to a bag and say "build me the few lines of code that will let people admin that bag". It's conceivable such a framework could exist, but it's not there today.
The other aspect to consider is deployment. If one is building an open-source framework with TiddlyWeb, which will have to be distributed and deployed by others, there is an additional pragmatic force in favour of keeping it all in the same unit and server, which must be balanced against the cleaner approach of separating concerns.
All Comments
* Client-driven - typically a Javascript web app, TiddlyWiki or otherwise, making RESTful calls.
* External server-driven - Django, Rails, Java, whatever server making server-to-server calls to TiddlyWeb
* Tiddlyweb-driven - A server somehow embedded in TiddlyWeb
While I appreciate the principle, I do think right now the third option is somewhat more appealing than the second option.
The main reason is that web frameworks like Django and Rails assume derive their considerable agility from making certain assumptions about the underlying persistence framework. The more you deviate from the typical case, the more these frameworks become cumbersome to deal with, and in unchartered ways.
There are probably plugins around that will deal with RESTful services in some way, but they won't be at all TiddlyWeb-specific. I can't, for instance, point to a bag and say "build me the few lines of code that will let people admin that bag". It's conceivable such a framework could exist, but it's not there today.
The other aspect to consider is deployment. If one is building an open-source framework with TiddlyWeb, which will have to be distributed and deployed by others, there is an additional pragmatic force in favour of keeping it all in the same unit and server, which must be balanced against the cleaner approach of separating concerns.