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

[Nick_Edgar@xxxxxxx]

I have a few more questions / points:

There is extra API for contributing and listening to the log.  See
org.eclipse.core.runtime.Plugin.getLog(), ILog, and ILogListener.

So in addition to the APIs on Platform (which duplicate 75% of ILog), there
is a log per plugin.  Each can have its own listeners.
However, currently all logs contribute to the same .log file.

Any API for retrieving log entries would have to take the per-plugin
scenario into account.  The proposal currently only lets you get at the
Platform log's contents.
If I ask a plugin's log for its entries, do I get just the entries for that
plugin, or all of them?
What should a UI present here, just the Platform log or individual logs per
plugin as well?

Also, simply serializing/deserializing the info available via IStatus is
not enough.  For example, org.eclipse.core.resources defines
IResourceStatus/ResourceStatus which extends IStatus/Status with a path
attribute, in addition to defining its own status codes.
The current log format does not capture such extra attributes.  This is
potentially valuable information which is getting lost.

In addition, it would be nice to have a human-readable representation of
the codes in any log UI (I don't believe this is guaranteed to be redundant
with the message).

If you want to save extra attributes and/or human-readable codes in the
log, the status object itself will have to get involved in its
serialization.
If you want to deserialize it as the same class, you will need to serialize
the class name and plugin name, and will run into plugin startup issues
(i.e. this is a non-starter).
As mentioned, you already run into some problems with deserializing
exceptions as strings rather than full objects, so you probably can't use
just IStatus as the result of reading the log.

It seems like a simple approach like publishing the XML DTD is looking more
and more tasty.  You could add convenience APIs for getting the location
for the platform log (or arbitrary ILog), and for pulling out key
attributes.  Having such APIs might make any UI (or other clients) more
resilient to any evolution of the DTD.  They may just be a convenience
though, since any evolution of the DTD would have to be backwards
compatible if the DTD is published.

I would still recommend allowing status subclasses to include their extra
attributes and human-readable codes though.

Nick



|--------+----------------------------------->
|        |          John_Arthorne@xxxxxxx    |
|        |          Sent by:                 |
|        |          platform-core-dev-admin@e|
|        |          clipse.org               |
|        |                                   |
|        |                                   |
|        |          12/06/01 06:45 PM        |
|        |          Please respond to        |
|        |          platform-core-dev        |
|        |                                   |
|--------+----------------------------------->
  >-----------------------------------------------------------------------------------------------------------|
  |                                                                                                           |
  |       To:     platform-core-dev@xxxxxxxxxxx                                                               |
  |       cc:                                                                                                 |
  |       Subject:     Re: [platform-core-dev] Comments on RFC 0003: Log File Retrieval                       |
  >-----------------------------------------------------------------------------------------------------------|




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>



_______________________________________________
platform-core-dev mailing list
platform-core-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-core-dev