[Bug tapsets/10697] Tapset for generation of XML-esque data

[Bug tapsets/10697] Tapset for generation of XML-esque data

[fche at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=10697

Frank Ch. Eigler <fche at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
                 CC|                            |fche at redhat dot com
         Resolution|---                         |WONTFIX

--- Comment #8 from Frank Ch. Eigler <fche at redhat dot com> ---
see also the pcp-oriented json generation code

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug tapsets/10697] Tapset for generation of XML-esque data

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2009-10-22 17:14 -------
> 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.


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=10697

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug tapsets/10697] Tapset for generation of XML-esque data

[chwang at redhat dot com]

------- Additional Comments From chwang at redhat dot com  2009-10-22 15:02 -------
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

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=10697

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug tapsets/10697] Tapset for generation of XML-esque data

[chwang at redhat dot com]

------- Additional Comments From chwang at redhat dot com  2009-10-22 14:52 -------
(In reply to comment #4)
> (In reply to comment #1)
> > Created an attachment (id=4233)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=4233&action=view)
> > 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.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=10697

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug tapsets/10697] Tapset for generation of XML-esque data

[anithra at linux dot vnet dot ibm dot com]

------- Additional Comments From anithra at linux dot vnet dot ibm dot com  2009-10-07 16:11 -------
(In reply to comment #1)
> Created an attachment (id=4233)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=4233&action=view)
> 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..



-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=10697

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug tapsets/10697] Tapset for generation of XML-esque data

[anithra at linux dot vnet dot ibm dot com]

------- Additional Comments From anithra at linux dot vnet dot ibm dot com  2009-10-07 16:03 -------
(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. 




-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=10697

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug tapsets/10697] Tapset for generation of XML-esque data

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2009-10-07 14:48 -------
Can you think of specific cases where the services provided by
the proposed tapset functions would be beneficial over hand-coding
the xml markup?

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING


http://sourceware.org/bugzilla/show_bug.cgi?id=10697

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug tapsets/10697] Tapset for generation of XML-esque data

[chwang at redhat dot com]

------- Additional Comments From chwang at redhat dot com  2009-09-26 21:45 -------
Created an attachment (id=4233)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=4233&action=view)
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.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=10697

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.