Re: library.gnome.org status

[Frederic Peters <fpeters 0d be>]

Hi Goran, (and gnome-web-list@)

You are in the same timezone as me, it will make things easier :)

> - 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...


> - There are no index files for browsing documentation by module or GNOME
> release, and removing old content on upgrade is totaly broken. There are
> small XML chunks (index.LANG.xml) in output that include informations
> like localized document title and abstract. My plan was to parse them
> after building is done and regenerate index pages. Index pages should be
> localized, and generated for each language avaibile.

I agree on the goal, it would also be possible to parse omf files to
get that information.  I would prefer to to this step, "decorating"
the raw xhtml files, with straight Python (+ a template language, I
have not been following that closely, genshi or kid come to mind).
In a second phase this generation could be moved to a web application
to support things like annotations...

/module/version/ -> generate list of languages + table of contents
/module/         -> generate list of versions
/                -> generate list of modules (and separate help from
                    API reference)

Is this easy for you to copy the .omf files in /module/version/ ?



> - Each tarball is extracted two times (once for gnome-doc-utils docs and
> other for gtk-doc API's). I am working on this. Generaly, I'm adding new
> class for each documentation source (GNOME FTP, GNOME SVN, etc) and then
> each locator (gtk-doc and gdu) can subscribe to some items at source.
> This way, content of each source is accessed only once. Also I'm adding
> global XML file representing content at source so upgrades can be
> handled easily. See http://goranrakic.com/tmp/library-web/design.html
> for some early specs.

I wonder if you could use published jhbuild modulesets (I come from a
jhbuild background, so this is kind of obsessive for me to use it)

You would monitor http://ftp.gnome.org/pub/GNOME/teams/releng/ for new
versions, then download (example)
  http://ftp.gnome.org/pub/GNOME/teams/releng/2.18.1/gnome-2.18.1.modules
and build it in whatever/build-2.18.1/.

So you only need one source for both stable releases and current
snapshots.  Then you would just need to listdir() whatever/build-2.18.1/
share/omf/ and get all help files that way.


> - There is no SVN driver. There is viewcvs driver (using HTTP GET and
> can work with ViewSVN as well) and jhbuild (using jhbuild checkout) but
> no SVN driver. Subversion has Python bindings so I think it is not that
> hard to make svn.py with same interface as drivers/cvs.py

I would suggest using jhbuild for everything :)


> If you agree, I suggest to plan a meeting at IRC or IM (Jabber:
> gox elitesecurity org) and decide on roadmap. First thing on a list is
> the biggest problem for me.

fpeters jabber org is my jabber id; we can also arrange a meeting on
IRC if other people are interested.



        Frederic