asset reorganization

[FND]

see commit messages for details

review from @cdent would be appreciated, particularly because this depends on cdent/tiddlywebplugins.imaker#3

[cdent]

I kinda see what's going on here, but there's a part of me that thinks "seems like a lot of effort".

This is especially the case when you consider that anyone who is using the static assets in earnest will really want to use whatever their HTTP host is to serve them as it will deal with the various headers (notably caching) without extra magic.

This of course returns you to the notion of "how to make those resources available" and what you've done here is come up with one more of several ways to do it.

This way may be right, but I'm not really sure.

What you might do is maintain the existing code which does the packaging of the assets into the package and then do two, no three things:

• merge your "read a static file from a package" stuff into tiddlywebplugins.static and basically tune that up as useful for minor installations and dev setups
• provide a quick script (not sure where, you've mentioned this elsewhere) which copies files out of the package into the proper static assets location for a big HTTP server
• make it easy to turn on twp.static in a dev or small scale setting

[FND]

seems like a lot of effort

Really? It seems comparatively simple to me:

• there are local assets, residing within the package
• there are third-party assets, downloaded into the package
• there's an application handler to serve these assets from within the package
• there will be a script to copy all assets from the package into a directory, to be served by the web server

• merge your "read a static file from a package" stuff into tiddlywebplugins.static and basically tune that up as useful for minor installations and dev setups
• [...]
• make it easy to turn on twp.static in a dev or small scale setting

Are you suggesting I replace my application-specific handler with an improved version of twp.static? I'd considered that (thus tiddlyweb/tiddlyweb-plugins#19), but the package resources approach seemed out of scope for the generic plugin.

[cdent]

Are you suggesting I replace my application-specific handler with an improved version of twp.static? I'd considered that (thus tiddlyweb/tiddlyweb-plugins#19), but the package resources approach seemed out of scope for the generic plugin.

That's pretty much what I was suggesting, yes. Not necessary of course, but it seems like a useful bit of generic functionality (static files in a dir or static files in a package). Presumably it could map different paths to different packages. My thoughts on "lot of effort" might be better stated as "this effort might be better in a more general context with efforts made to reuse some existing stuff or at least make the new stuff reusable".

[FND]

merged (plus script in 1d7f61f72147544125897099aa183683195684e1)