[platform-core-dev] RFC 0003 - Log File Retrieval,

["Greg Adams/OTT/OTI" <Greg_Adams@xxxxxxx>]

The proposal indicates we need to do this, but doesn't provide any use cases to show why, or how it will get used. Consequently it makes it harder to evaluate, and in fact even commenting on xml vs. plain text can be misleading without this information.  So let me pre-apologize if my comments are off base - I'm trying to cover as many possible cases as I can think of. No growlyness is intended.

----------------------------
*        Why are we looking to show the contents of the log while eclipse is running. The eclipse log typically contains rude  (i.e. developer oriented) information . This seems to suggest it may not be appropriate to show to a user.  - OR -  Are we looking at this primarily as an assist facility for plugin developers.
----------------------------
*        Rodrigo indicates: "Instead of changing the format to XML, we should just have an 
additional log.xml file as well as the current .log file. The current  format is much easier for humans to read (and currently helps a lot) than if you add a bunch of XML tags to it."

        - My recollection is that the text format was itself not "ideal" for human consumption (in fact the proposal indicates this). Although it did not include xml-tags-a-plenty it was still not ideally suited for presentation to a user. I would argue that you have a ui presentation issue for both formats. Thus my claim is if we go with xml there is little benefit to also keeping a text file.

        - If we go with XML it seems that we may want richer api to both contribute to it, and to read it back. That is, api allowing the contribution/access-to of various elements & attributes - to support richer descriptions.  This in fact is the argument for why xml is better then free text. Alternatively you could impose a strict format to the lines of the text file - but this is less "obvious/explicit" 

        - Related to the above is how we expect clients to access the log.  Do we expect clients to want to get the log as a big wad, or be able to get the entries of the log. If clients want to work with entries (e.g. showing them in a table) then it argues you need entry oriented api, either with xml elements or possible a log entry class/interfaces? Each entry in a ui table would then be one of those (much like the task list is markers)
----------------------------
*        The problem definition talks about listeners etc. - presumably so that we can present additions to the log as the eclipse is up. However I did not actually see anything in the solution specifically targetted to this. What did I miss?

        This would be useful so that the ui could say "hey something new is in the log" let me show you the new problems.

----------------------------

*        I don't like the idea that the xml dtd would be non-api  BUT   I would be ok with it  if there was api to work with the entries. That is the actual file representation can be non api provided the coding api is rich enough.

        What is the proposed api for dealing with the log - retrieveLogContents is insufficient beause its just a big wad and makes the clients do all the work and moroever if the dtd is non ai the clients can't even rely on the form of the elements.

----------------------------

*        Will the log be vaporized on shutdown/restart?

----------------------------