WardCunningham
can we move the views html and css into DefaultData?
server / sinatra / views contains template definition data on how to render.
This is currently used by the node.js (html) and sinatra (haml) servers and by the static server .htaccess setup (html).
Also, my moving that into the data dir, we're allowing local customisations, which I'm also interested in.
Sounds like a good idea. Can we get a specific proposal?
I'm a little worried that the development workflow might get too complex if we have to edit in default-data and then test by moving content to data with each run.
Maybe we need a better deployment strategy. For "devops" I've been using git pull.
ok, specific proposal:
in the interests of duplicating things, fed.wiki's will contain 2 data dir's:
- the default-data, containing the default data
- the data dir, containing all local data
modifications to the default-data will do a 'copy on change', thus causing the server to ignore the file in the default-data dir if it finds it in the data dir.
both the default-data and data dirs can contain pages and views dirs and client??, and ?? only the data dir will have a status dir??
(it seems to me that in many ways the client code (plugins especially) are data that can be customized locally - and from the foswiki/twiki lesson, the sooner customisations are locally but separably trackable, the better.
starting a server with no data/status/local-identity will have one created for the user (or even better, will cause the user to tell it what to enter - either by exiting and insisting on parameters with the needed info, interactive questionnaire, or insecure webUI that could also see that user 'claiming' that instance...!
I understand this proposal as having two parts:
- default-data like semantics for static content like html and css
- default-data like semantics for plugins
The first part addresses how you would configure a new site. In particular, you wouldn't want a git pull to clobber customized css. I have imagined that css customization would be done by designers to match related properties.
The second part addresses how you would add new or revised plugin capability to an existing site. I had imagined plugin management would be done by programmers through sharing mechanisms like GitHub. I'm now thinking that some sort of automation might be possible without creating a virus distribution network. See http://code.google.com/p/google-caja/ for example.
Let's not let deep thinking about part two get in the way of making small adjustments suggested in part one. Also, let's let development convenience dominate for a little longer. Thanks.
Very good conclusions, Ward. For SFW, putting development convenience first makes a lot of sense as long as you don't loose sight of secure deployment issues in the design. In other words, it is fine to have a "lax security mode" of exchanging plugin code with your development network, but there is no way I will be allowed to deploy code this way in production mode.
SFW isn't in production mode, and it may never be run that way, but I fully expect that related derivatives will be, and they will need a secure way to share plugins.
In the end, this is mainly an issue of social engineering and process architectures. The difference between development and production is how the code is "blessed". The way we talk about this with respect to Wagn is to introduce the idea of conformance to an API or specification and that will probably include both passing acceptance tests and code review (by the development communities). As is common practice in open source communities, there would be common code repositories and different levels of review and testing are indicated by promotion to different repositories. The communities define the terms used to describe the level of confidence, "stable", "development", "production", "alpha", "beta"; the labels are totally arbitrary, but they make it easy to know what code you should be looking at when.
