Re: Community Documentation Architecture, was LaTeX templates, was Docmentation/FAQs

["Chris Travers" <..hidden..>]

At some point it will become difficult to migrate between the
applications as the core functionality moves farther apart.  However,
for the most part, I htink we should support migrations to our
software from as many applications as possible.

I expect this point of no return to be a bit over a year out, given
the current rate of progress with SQL-Ledger.  SQL-Ledger tends to run
on an 12-18 month release cycle between major upgrades and we need to
support migrating from at least the next one (which I expect to be out
in the next couple months).

However, the point at which it is difficult  to migrate from LedgerSMB
to SQL-Ledger will happen much sooner (perhaps within the next month
or two) given our current rate of progress.  It is possible now, but
it will be much more difficult once we start making more significant
database changes.

Now regarding going with an all-XML template system, I think it is
*WAY* too soon to even be considering this.  Furthermore, I don't
think it to our benefit to suggest that people who move to our
software will need to redo all their custom templates at this time.
A few things to consider:
1)  We don't even have an alternative to the current template system
in place....
2)  XML is overkill for simple Text-only receipts for POS thermal or
dot matrix printers.  Currently I have non-programmer customers who
edit their own POS templates simply because that is easy to do under
the current scheme.
3)  If you go with an XML->PDF solution, you will either need to have
a direct XML->Level 1 Postscript solution in order to accomodate older
postscript printers or use LaTeX as an intermediary (so you can do
this).
4)  This would require that all users migrate all their custom
templates or plan on doing so before joining our project.

The proper way to do this IMNSHO is to offer the alternative and then
discuss deprecating other formats when and only when the following
criterial are met.  Either:
1)  Significant technical challenges exist to supporting multiple pathwats or
2)  The older system simply isn't used anymore.

Neither of these exist, and so I think we should drop this discussion
until such a time as they are.  If an XML format becomes sufficiently
helpful that people stop using the old system even for the simplest
fixed-width POS receipts, then we drop it.  Otherwise we keep it as
long as we can.

Note that the preprocessor for 1.2 embeds well in XML (which
SQL-Ledger's does not).  It wouldn't be out of the question to support
the following tool chain:

Preprocess text file (XML, LaTeX, etc) if necessary.
Transform text file into desired format if necessary.

Note that the preprocessor could also be used to create very simple
XML API's.  But different preprocessors and different transform
programs could be plugged in at each stage as desired (or omitted
altogether).

In short, what I am suggesting is that let us build a generic
infrastructure that doesn't care about the details of data
presentation and then let the complex demands of the current and new
users shape the future of the software.

Best Wishes,
Chris Travers