Cart
[Home] [By Thread] [By Date] [Recent Entries]
> Doesn't seem like a good tradeoff just to read logfiles, especially when there's already work-arounds (which don't make the world catch on fire). I don't see how you can tell what's
a good tradeoff without knowing anything about the cost of development or
the cost of failure, which are both highly variable by
project.
The right tradeoff
for me on a couple of projects has been to use
the workaround where log entries are added to a file containing a sequence
of elements with no outer wrapper, and that file is read by referencing it as an
external entity inside a document entity that serves merely to add the wrapper.
That gives me as much reliability as I need (which on these projects is not that
much) and more development inconvenience than I want. I could get the same level
of reliability without the inconvenience if the spec allowed me to parse the
unwrapped-list-of-elements directly - so the restriction in the spec is buying
me nothing, therefore it can't be a good
trade-off.
In any case, if the process writing the file fails with
a disk-full error, and I want the system to be resilient to this, then
surely I should deal with the disk-full exception, rather than by assuming that
the failure will leave the file in an unreadable
state?
Michael Kay
http://www.saxonica.com/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
