<html> <head> <meta content="text/html; charset=UTF-8" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> Hey folks, On 03/12/2012 09:35 AM, Andrew Hecox wrote: > On 03/12/2012 10:17 AM, Bryn M. Reeves wrote: <blockquote type="cite">On 03/12/2012 01:00 PM, Andrew Hecox wrote: >>>> tar archives provide a journal/manifest of the names of files, >>>> and where they are. Because tar is a well known file format, >>>> there are already language bindings in place for everything >>>> anyone would want to do. Unfortunately this does not solve the problem; as I mentioned before the tar structure should be considered an ABI. It is subject to change and is not discoverable in a way that will support upcoming changes in a robust way. </blockquote> But, a manifest that just lists the file contents doesn't' provide any benefit over what we already have. What I'm interested in is what "upcoming changes" you envision. That should be driving the need of a manifest. I.e., we don't need a manifest now, we only need it when we have those changes and, thus, the manifest becomes part of those changes, not a separate thing. <blockquote type="cite">> I'd guess to most consumers, the logical layout & content is an API found through tar bindings for whatever your specific languages are. For instance, sos will soon need to have the ability to collect the same configuration file from multiple locations and to record this information in the archive. While it would be possible to search all archives for all possible paths this is inefficient and prone to failure. For instance, if we change the set of command line options used to run a program the path in the tarball will changes as might the content present at that path. > what are these "same configuration file from multiple locations" use-cases? > -Ah This also cannot address more complex manipulations of the data than a simple "read this data from this path". In looking at the tools that consume sos data there is huge overlap and commonality in the information that they retrieve and the processing that they carry out. Reinventing this in each project that has overlapping requirements is not maintainable long-term and will hinder sos's ability to adapt to meet changing requirements (since there will be pressure to not make changes that would affect downstream consumers). </blockquote> Here, too, what are these use-cases? I think that we need a fairly high bar to do any processing beyond "read this data from this path." I.e., nearly all analysis should happen server side. Commonality can happen on the server-side analysis libraries. Also, I'm I also am interested in how opaque you are thinking the report should be. The implication here is that it is completely opaque and should only be accessed through an API. Is that the thought? (If so, I have many reservations.) Cheers, Mike C. </body> </html>