Re: [platform-core-dev] Comments on RFC 0003: Log File Retrieval

[John_Arthorne@xxxxxxx]

See my <JA></JA> comments below.



The log may be very long, especially considering the changes mentioned in
the plan to keep the log around longer than a single invocation.
It may be very memory-space intensive to read the whole thing in.
I recommend adding a parameter to retrieveLogContents specifying how many
items to retrieve (presumably starting from the end).

<JA>That's a good suggestion, thanks. "tail .log"...</JA>

It would be also be nice to be able to determine how many entries there
are, and retrieve an arbitrary range, but this would require more
information in the log file format to do this efficiently.
For example, imagine a view which lets you scroll or page through the log
without having to read the whole thing into memory at once.
This is probably less important than simply allowing a bounds on the
number of entries read.

<JA>I think there's a danger of trying to get too fancy with this.  In the
end it's just a simple API to aid developers, and in the worst case the
developer can browse/grep the log file manually.  With the richer XML
format, one could easily imagine wanting to do things like:

- return all statuses of a given severity
- return all errors that throw a given exception class
- return all log entries created within a given date range.

But honestly I think we've got more interesting features to work on.  One
alternative is that we expose the log filename and DTD as API so third
parties can write whatever kind of fancy log reader they want...</JA>

Question: It looks like the log API only allows it to contain IStatus
objects.  Is this any more restricted than the current support?  I guess
not, but thought I'd ask.

<JA>Nope, this matches the converse API for writing to the log, which only
allows IStatus objects to be written.</JA>