Guys, as you can see in my patch it contains just the background,
foreground, selection back and foreground color and so on. Maybe the
Terminal color scheme should support the colors for the ANSI control
sequences too. What do you think? So can we control everything, what
now impossible (? FIXME), and it would be the samein every supported
CLI app.
Best Regards,
miqlas
2015-09-02 13:48 GMT+02:00 Adrien Destugues <pulkomandy@xxxxxxxxxxxxx>:
In the case of color schemes, you want the BMessage to use rgb_colors, but
you probably want the
generated XML to be in a format similar to (and compatible with) what other
software uses. If your
xml is a direct mapping of the BMessage it would probably look like this:
<message>
<item type="rgb_color" name="foreground" value="0xFFFFFFF"/>
</message>
Something like this is actually more readable/modifiable than anything
serialized in a binary blob.
Not by much. Do you know, without thinking, that FFFFFFF is opaque white? Can
you tell what color are 5453245, 4543262?
As you see, the text-based format does not make this more confortable to
edit, in the case of colors. It is more readable/modifiable than a binary
blob, but why would you need to modify it directly?
On the other hand, if you start with an existing syntax, and manipulate it
using for example the
XmlNode class I linked, you have to navigate it the XML way (so you
manipulate attributes and
nodes).
It is unlikely that you can do a message.FindColor() on it.
I think BMessage itself could do very well the serialization part, e.g. you
want to transfer some
XML over the web, then serialize a BXMLMessage that would be more or less to
cast it to a BMessage.
I don't pretend BMessage to be extended to support xml nodes, but i would
like to be able to
translate my BMessages in a more readable form. Or inversely, to be able to
serialize them, send,
and on the other end retrieve the original BXMLMessage. That's just a name,
but we may end up with
something more, at least OpenBinder had a BContent class.
If it's just for debugging, there is BMessage.PrintToStream() for looking at
a message contents. It is not an easy format to parse back into a BMessage,
however.
For sending them over the network there is little point in using XML. You can
use BArchivable and put them into a BDataIO in binary format, which will be
more efficient. And for debugging, you can write an appropriate tool (there
is "message" to dump BMessages archived to a file, probably it can be used
with netcat, or we could make a wireshark plugin, etc).
XML is supposed to be readable easily both by humans and computers, and it
failed. It is complex to parse, both for humans and for computers, when
compared to other formats, either binary (protobuf, ASN.1, ...) or text-based
(JSON, ...).
There are more problems such as properly encoding raw data added to a
message with AddData()
(probably it will need base64 or something similar),
Isn't it already the standard?
There is not yet a standard DTD for converting BMessages into XML. We could
decide on base64, check if the data can be represented as utf-8 and use that,
use CDATA, use uuencode, or some more compact encoding.
preserving the distinction between children nodes and attributes from XML
to BMessage, etc.
I don't think this is a so hard problem to solve. I can see various projects
or APIs that support
some sort of serialization <-> XML even for IPC purposes.
As I said there are two different matters:
* Serializing a BMessage to XML and unarchiving back to a BMessage is easy,
but does not give you a great advantage over the existing binary-based
encoding except in some edge cases. This can't be fed with any XML with
reasonable results
* On the other hand, parsing "any" XML file and representing it in some
useful and easy to handle format. XmlNode does this, for example, but it is
probably simpler to use the existing and industry-standard ways: SAX and DOM.
And to use these, we can rely on libxml or a similar existing library. Is
there really a need for a BeAPI-ish wrapper on these?
In the end you probably are better off parsing your XML in a traditional
way (SAX or DOM) and
populating your BMessage from it using ad-hoc code depending on the actualy
contents (not syntax)
of the data you are trying to parse.
The first thing is to have an xml_kit, then we can think if we want to allow
some compatibility
with BMessage. But even if adding this compatibility isn't possible, XML is
a today standard and we
need to support it. In the current case of a color scheme, i think XML is
the best choice.
I think it's not. You can't see the colors in the XML, just numbers. So who
will really want to edit the file manually? It's easier to use Terminal
settings window or another color picker to build your color palette, than
manually enter hex-digits in a text file. I think it is one of the worst
examples you could have chosen, sorry :)
--
Adrien.
