Re: [Scrollkeeper-devel] Scrollkeeper delay

[Malcolm T. <ma...@co...>]

On Sat, 2003-06-21 at 13:17, Dan Mueth wrote:
> On 21 Jun 2003, Malcolm Tredinnick wrote:
> 
> > On Sat, 2003-06-21 at 00:52, Dan Mueth wrote:
[...]
> > > The real solution to this problem is to extend ScrollKeeper so that one 
> > > can process the docs at build time and install the generated data so that 
> > > ScrollKeeper doesn't have to do it at install time.
> > 
> > Can you explain this a bit more, because I am stupid and do not
> > understand. :-(
> > 
> > We already run scrollkeeper-preinstall in the build phase and
> > scrollkeeper-update in the install phase. So it sounds like you are
> > proposing some kind of optimised output from the build phase so that the
> > update part will be faster at install time, but, like I said, I don't
> > really understand.
> 
> When we build a package, ScrollKeeper is actually run in a way that it 
> generates the metadata files from the document and writes them to files.  
> However, these files are not kept in the package.  They are just left in 
> the temporary build tree and then are later destroyed.  The reasoning is: 
> (1) We want to generate and install (in the temporary path) the metadata 
> to make sure any errors are found, and (2) We don't keep and install the 
> generated metadata because you have to worry about compatibility between 
> different versions of ScrollKeeper and potential customization of 
> stylesheets on different systems.  At install time, the metadata is 
> re-generated from the original documents, which is why ScrollKeeper makes 
> package installation time grow dramatically for packages with long 
> documents.

Oh, doh! Sorry, I was thinking along the completely wrong track when I
posted earlier -- I don't think I had quite woken up yet. All is
clear(er) now, I understand what you are getting at.

> The original hope was that we would win the speed race... that libxml and
> computers would both speed up faster than the documentation body grows and
> that the package installation time would not be too painfully lengthened.  
> Since this is not the case, we need to consider the other options which we
> originally wanted to avoid (things like pre-generating and installing the
> metadata, using cron to process metadata at a more convenient time,
> backgrounding the metadata generation, etc.).  They all have their 
> drawbacks, but it sounds like we need to provide at least an optional 
> workaround so that distributions have a way to avoid lengthening 
> distribution installation times significantly.

Agreed.

> As for scrollkeeper-preinstall, it is simply a little utility which 
> modifies an OMF entry to include the actual path that a document will be 
> installed at, since this is generally not known until build time.  It 
> doesn't actually read or process the document itself.

Yes, I understand this. Sorry, not meaning to confuse the issue: I had
completely misunderstood where you were going earlier. Now I feel silly.

Still, no harm done. There is stuff to think about here.

Cheers,
Malcolm