[publican-list] Redundant common content files when publishing books

[Jeff Fearn]

On Thu, 2010-03-18 at 11:37 +1000, Darrin Mison wrote:
> When publishing a number of books using the same brand each book ends up with their own set of common content files.
> 
> This is problematic for a couple of reasons:
> 
> 1 - many uploading/publishing systems are often problematic when dealing with large numbers of files
> 2 - increased webserver traffic as the common content is not shared & therefore not cached optimally
> 
> Perhaps merging common content on a brand basis could be an option when building books using the upcoming website generation feature ?
> 
> Or be able to specify the required path(absolute or relative) for pre-published common content as a publican configuration when building the book ?
> 
> eg.
> docs
> `-- en-US
>     `-- MyProduct
>         |-- Common_Content
>         |   `-- JBoss
>         |       |-- css
>         |       `-- images
>         |-- Config_Guide
>         `-- Install_Guide
> 
> 
> Thoughts ?

You can either have one copy of the common content for everything or one
per book, nothing else is really maintainable.

e.g. The example above won't work on an RPM based system unless you
create a brand RPM for each product or modify the brand RPM to install
the content in every location it might possibly be used.

If you have one copy for every book using a brand, when you update the
brand you have to rebuild all the books that use it to ensure the books
render properly. You can't be sure there isn't some change that affects
how older content is displayed with newer styles, particularly if you
change the XSL and not just the css.

Of course if you are changing the css you are probably changing the PDF
to match and now your HTML and PDF of the same book and version are out
of sync; so rebuilding the package is the obvious choice for sanity.

Since it won't affect me I'm not really fussed ... but I imagine the
writers might get a bit narky if they have to rebuild hundreds of books
regularly ... maybe that's OK though :P

Cheers, Jeff.

-- 
Jeff Fearn <jfearn at redhat.com>
Software Engineer
Engineering Operations
Red Hat, Inc
Freedom ... courage ... Commitment ... ACCOUNTABILITY