I'm slow, but it did hit me that there may be a simpler solution after all. I gather that the problem is that the user's output could have tags in it that match our own, thus causing tag-confusion. True?
My concern is that our proposed solution generates pidgin-xml which could only ever be translated by a specially written parser. Kinda makes xml a little moot in ways.
What if we simply change the name of our tags to something ompi-specific? I could tag things with <ompi-stdout>, for example. This would follow the natural naming convention for internal variables, and would avoid any conflicts unless the user were truly stupid - in which case, the onus would be on them.
Would that resolve the problem?
On Mon, May 25, 2009 at 9:10 AM, Greg Watson <email@example.com> wrote:
In life, nothing is ever easy...
While the XML output is working well, I've come across an issue with stdout/stderr. Unfortunately it's not just enough to wrap it in tags, because it's possible that the output will contain XML formatting information. There are two ways to get around this. The easiest is to wrap the output in "<![CDATA[" and "]]>". This has the benefit of being relatively easy, but will fail if the output contains the string "]]>". The other way is to replace all instances of "&", "<", and ">" with "&", "<", and ">" respectively. This is safer, but requires more processing.
"Ick" immediately comes to mind, but is hardly helpful. :-)
I am already doing some processing to deal with linefeeds in the middle of output streams, so adding these three special chars isn't -that- big a deal. I can have a test version for you in the next day or so (svn trunk) - I am on reduced hours while moving my son (driving across country).
Let's give that a try and see if it resolves the problem...
devel mailing list