As a possible lead-in to some graphing stuff on Eclipse, I sketched a little stap set for xml generation. If it would be useful to other users of systemtap, I would be happy to clean it up a bit and submit :) [If not, it's also all right :)] All print functions maintain proper tabbing for human readability. Functions: opentag(string tag) -- prints <tag>. Tag can be a name ("hello") or a name plus key-value pairs separated by spaces ("newtag this=that who=what") addattr(string keyvalue) -- gives the given key-value pair to the currently open tag. closecurrent() -- closes the current top-level tag by printing </tag> closetag(string tag) -- prints </tag>. Not recommended, use closecurrent() instead. openclosetag(string tag) -- convenience method to create <tag/> closeall() -- closes all open tags. Recommended to use this in probe end or probe error so you can get fully formed data in all cases. setlimit() -- sets the maximum number of tags to keep in memory. Defaults to 100. If this number is exceeded, no new tags are opened. [Currently causes opentag to return -1, no other error message generated] Brief example: stap -e 'probe begin{opentag("BLAH newattr=oldattr") addattr("this=that") closetag("BLAH") opentag("newtag") opentag("anothertag") addattr("stap=yay") openclosetag("single attributes=many") closeall() exit() }' <BLAH newattr=oldattr this=that> </BLAH> <newtag> <anothertag stap=yay> <single attributes=many/> </anothertag> </newtag>
Created attachment 4233 [details] Current version of the markup script Brief sketch of proposed script. Somewhat arbitrary/possibly inefficient in the way it keeps track of open/closed tags and what needs to be printed.
Can you think of specific cases where the services provided by the proposed tapset functions would be beneficial over hand-coding the xml markup?
(In reply to comment #2) > Can you think of specific cases where the services provided by > the proposed tapset functions would be beneficial over hand-coding > the xml markup? I didnt understand exactly what you mean by hand-coding the xml markup.. but Charley's xml generation functions would definitely be useful in tools that are developed based on systemtap (like SystemTapGui). xml based output would help to standardize the output to a certain extent and allows for easy parsing. A lot of eclipse-based tools work with xml output as we already have an xml parser which would make it easy to interpret and use xml output in graphs or otherwise. The other option would be to use an xml adapter to convert the output into xml format, but this is definitely more straightforward and easier to use.
(In reply to comment #1) > Created an attachment (id=4233) > Current version of the markup script > > Brief sketch of proposed script. Somewhat arbitrary/possibly inefficient in the > way it keeps track of open/closed tags and what needs to be printed. Any thoughts on how we could use this with dynamic output?. I'm thinking of scenarios where we might want graphs to parse the output and update dynamically . We would need the xml output to be consistent/fully formed at all times , not sure if thats feasible..
(In reply to comment #4) > (In reply to comment #1) > > Created an attachment (id=4233) > > Current version of the markup script > > > > Brief sketch of proposed script. Somewhat arbitrary/possibly inefficient in the > > way it keeps track of open/closed tags and what needs to be printed. > > Any thoughts on how we could use this with dynamic output?. I'm thinking of > scenarios where we might want graphs to parse the output and update dynamically > . We would need the xml output to be consistent/fully formed at all times , not > sure if thats feasible.. > > I'm not sure how to keep the XML fully formed without using embedded C to insert into a file, but maybe you can pretend that closing tags exist? I did something similar to build a (really) basic real-time XML-esque grapher. So for example the script outputs: <tag1> <tag2> <tag3> and the reader will read that as [the round brackets indicate are imaginary tags) Read <tag1>: <tag1> (</tag1>) Read <tag2>: <tag1> <tag2> (<tag2>) (<tag1>) Read tag3: <tag1> <tag2> <tag3> (<tag3>) (<tag2>) (<tag1>) In my case the closing tags didn't even matter except to keep track of which node to append data/nodes to, so it worked out pretty well.
Wait, I think I understand what you mean Anithra, and it's different from what I just tried to say. I think we can keep the XML fully formed if we first make a tapset for file manipulation (so we can insert into a file) -- would this be useful to you? Alternatively Roland and I could build a reader program that completes the XML before passing it off to a standard parser. File manipulation sounds like it would be useful, but with stap's enhanced privileges it could also be very dangerous without restrictions on the location of the file... Thanks, -Charley
> Any thoughts on how we could use this with dynamic output?. I'm thinking of > scenarios where we might want graphs to parse the output and update dynamically. Encoding plain time series data in full XML seems like a solution looking for a problem. Graphing general XML data streams is probably in the domain of a more general tool - something with xquery or whatnot - and one that can handle streamed xml that's not fully formed.
see also the pcp-oriented json generation code