Re: library.gnome.org status

[Shaun McCance <shaunm gnome org>]

On Mon, 2007-04-16 at 23:07 +0200, Goran Rakic wrote:
> У пон, 16. 04 2007. у 14:03 +0200, Frederic Peters пише:
> > > - XSLT styles (locators/gtkdoc/gtkdoc.xslt and locators/gdu/gdu.xslt)
> > > are not producing markup acording to mockups. Main problem is that there
> > > is no navigation sidebar. I also don't know how to include list of
> > > languages avaibile as some languages can fail to build (maybe script can
> > > try to build all languages first and then reprocess them to include
> > > language selector, but that is far from optimal solution)
> > 
> > As I said in my blog post, my XSLT skills are rusty; also from
> > previous experience I don't think it is wise to do everything using
> > XSLT.  See next paragraph...
> 
> When I started my SoC project, doing everything in XSLT was one of
> requirements. Indeed, it is the easiest way as we can reuse same XSLT
> from gnome-doc-utils and gtk-doc. But we need to write this patch once,
> to include web specific options. I guess we must then beg Shaun to do
> the work. :)
> 
> Another thing is that I would really like to keep things static, and
> annotations can be plugged in via javascript (and them can be dynamic,
> as they need to be). I don't see any advantage of having static content
> served dynamically. 
> 
> And about your idea of using output from xsltproc as input in another
> processing, I think that would be too expensive, witout any reason
> except list of languages. Everything else can be done in XSLT, just I
> don't know how to do it. :)
> 
> List of languages is a problem as when, for example, language number
> four fails to build we need to process languages 1-3 again (to remove
> language four from the list). But instead doing that, we can just remove
> output of lang 4th and Apache will serve English as a fallback (and we
> are always building English first, and other langs only if English is
> built correctly).
> 
> What do you think, can we do that or do you think we should process
> languages 1-3 to include new list of languages (without language 4 in
> the list) or we should apply another transformation (from Python or
> another XSLT) to include list of languages on every page after building
> is done? Remember then second processing will be expensive as we need to
> process every chunk, not just one single document.

Can't we just use server-side includes?  I once wrote some
SSI/CGI for exactly this purpose.  Each page would have an
SSI directive that included the results of a CGI script.
The CGI script was like ten lines of sh that just checked
for the existence of the page in other languages and then
printed some links.

Alternatively, we can avoid the CGI and just SSI include a
static file of links.  This file can be generated by libgo
after it knows exactly which languages built.

But then again, maybe we should just fix the documents
that are failing to build.

--
Shaun