On Oct 17, 2009, at 9:04 AM, Tilman Sauerbeck wrote:
Henrik Gustafsson [2009-10-15 23:55]:
On Oct 15, 2009, at 11:45 PM, Henrik Gustafsson wrote:
I think the most backwards compatible solution to do it like with
the signal/broadcast commands, adding <id />-tags to the methods
and objects. Of course it's more to maintain for each
object/command, but I think the only massive work the creation of
the initial ids. I made a patch to add just that (applies to
ffb6e7e7 of xmms2-tillman.git on the genipc branch). XML and
schema updated, and the xml even validates afterwards :)
No attachments, eh?
http://fnord.se/dump/add_ids.diff
I'm not really convinced that setting IDs explicitly is needed, but if
everyone else thinks this is the right way I'm okay with it.
I just don't like the idea of id-numbers derived from an algorithm
involving magic offsets and the order of lines in a hand-edited
documents :)
Some comments on the diff:
+ <xs:simpleType name="signal_id">
+ <xs:restriction base="xs:integer">
+ <xs:minInclusive value="0"/>
+ <xs:maxInclusive value="31"/>
+ </xs:restriction>
+ </xs:simpleType>
I don't think that the upper limit is 31. I think you might have mixed
this up with the number of reserved/special method IDs, which are
0-31.
Yup, sure did, well spotted :)
+ <!-- ID type for methods -->
+ <xs:simpleType name="method_id">
+ <xs:restriction base="xs:integer">
+ <xs:minInclusive value="32"/>
+ <xs:maxInclusive value="2147483647"/>
+ </xs:restriction>
+ </xs:simpleType>
Should we really expose this 0-31-is-black-magic-and-shouldnt-be-used
thing on the IPC description? I think I'd rather see us use IDs
0..2147483615.
IMHO it's better to have it explicit than implicit. Just stop calling
it magic and officially reserve the range and it all makes sense, I
think.
I'll just throw out a few fringe ideas to get them off my chest before
moving on to your next mail:
Introducing
<xs:simpleType name="response_id">
<xs:restriction base="xs:integer">
<xs:minInclusive value="0"/>
<xs:maxInclusive value="31"/>
</xs:restriction>
</xs:simpleType>
and specifying the reply and error messages in tems of that might
work. Although I'd actually prefer if there weren't any reserved/magic
numbers at all, perhaps using a flags field somewhere to indicate the
status;
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|R|S|r|r|r|r|r|r|
+-+-+-+-+-+-+-+-+
R - 1 if the message is a response, 0 otherwise
* If the message is a response, the cookie field must match
the cookie value of the initiating message.
* If the message is not a response, the cookie field should
contain a value that is unique among the cookie values of
all outstanding messages.
S - 1 if the message indicates an error condition, 0 otherwise
As a side effect it would define the semantics of the cookie field
rather nicely as well. Now where to put this is another question
altogether, but personally I think 2^24 objects or methods Should Be
Enough For Everyone<tm>, but I realize that's probably not how you
want the protocol designed :)
// Henrik
--
_______________________________________________
Xmms2-devel mailing list
Xmms2-devel@lists.xmms.se
http://lists.xmms.se/cgi-bin/mailman/listinfo/xmms2-devel
