On 06/28/2010 05:11 PM, Bernd Eilers wrote: > There is a lot of "non-static" content on a website like OOo. Stuff > which is based on who is the user currently being logged in, which > access privileges and roles in projects has he/she, which projects do we > currently have, ... > which files have been recently added to a project, etc., etc.
That's all script material. Who's logged in, if you mean HTTP Auth, then that's just guess based on last access. If you mean who's tunnelling CVS, then that's something like "w | awk '...'" Access privileges, roles and projects would be a matter of polling the versioning system, I guess. > ... which mailinglists do we currently have, who is > subscribed to which mailinglist, what are the contents of the > mailinglist, what are the access rights and other settings for the > mailing list... Those items are probably taken care of by Sympa, if I understand the documentation correctly and if it works similarly to Mailman or Majordomo. > The information for generating such dynamic content is typically stored > in a database and things like JavaServlets, JavaServerPages, ruby on > rails or perl are used to generate webpages interacting with the database. Superficially the above looks like it can be managed without extra databases, etc. Again maybe a front end JSP or CGI. > There may also be some dynamic content inside the "decoration" of an > otherwise static webpage eg. displaying the username in the header or That's what SSI is designed to do and one of the main reasons I bring it up in the first place. http://httpd.apache.org/docs/2.2/mod/mod_include.html > elements depending on the members roles in projects inside the added > navigational elements. SSI includes access to the same environment variables that the HTTP daemon has. If that include the user and groups, then they can be used to make decisions. It does have the ability to run conditional statements. http://httpd.apache.org/docs/2.2/mod/mod_include.html#flowctrl > And it is not only a publication framework it´s also a collaboration > tool ;-) I see. A publication framework only goes up to 10, but a righteous collaboration tool goes up to 11. ;) >> While Kenai project is being worked on, XHTML+CSS+SSI lets the work get >> done for the OOo project. The sites can be grabbed as-is using wget (or >> other harvester) recursively. Then footers, headers, menus can be made >> for each OOo sub-project and links substituted. > > Well for prototyping yes. But a real thing does need more than SSI to > handle all the dynamic stuff. Sympa to handle the mailing lists. SVN / CVS to handle permissions, maybe a little perl or ruby glue for the CVS or SVN polling. > ... And you certainly want to use the pages > from CVS without the decoration or grab/wget their /nonav/ version and > not really duplicate header, footer, etc on each page of course. Yeah the wget was a less than optimal solution, but an example that works. The CVS checkout would use less space. However, parsing either using an XML or XHTML parser (e.g. HTML::TokeParser) would be about the same work to prepare. >... Funny to hear you referencing "The Mythical Man-Month" and estimating > efforts in hours though ;-) I tend to think in terms of how long it takes (or had previously taken) me to do various repeated tasks. >> When I tried tweaking the appearance of it in 2001 or so it took only a >> few hours (after initial set up) to add banners, etc. > > Well that´s nice to hear. FWIW Request Tracker was easier to work with and set up, but both have changed a lot since then. Anyway, the idea is that whatever happens at the OOo site, it will use XHTML and CSS and have various page elements. SSI can give us *most* of that *now* because it is built into Apache (see "IncludesNOEXEC") and available for nginx. Much of the rest of the functionality is covered by the other software used. Mailing list software has its own web interface. There are several web interfaces for SVN and there are several ways to integrate bugzilla with SVN. Maybe the only odd one out would be the user database, which could be managed by mod_auth_mysql. Relatively little 'glue' is needed. Regards, /Lars --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
