[Xcb] GSoC 2009: XKB and XI2 support
mceier at gmail.com
Wed Sep 16 09:23:17 PDT 2009
Peter Harris pisze:
> On Wed, Sep 16, 2009 at 11:12 AM, Mariusz Ceier wrote:
>> Peter Harris pisze:
>>> On Tue, Sep 15, 2009 at 5:55 AM, Mariusz Ceier wrote:
>>>> - replyof - makes copy of reply of given request a field of other
>>>> request, e.g.
>>>> <replyof request="GetMap" name="map" />
>>> Why? Can this not be done using the copy/paste function in your
>>> editor? Or did I misunderstand the purpose of this syntax?
>> Everything can be done this way :) If attached diff is acceptable I can
>> merge it.
>> replyof is something like field with type of reply of some request,
>> instead of some structure.
> Hmm. Those are rather large. Do you think it makes sense to put those
> blocks into a struct that you can use from multiple requests/replies?
> Either way, that still looks better than adding even more syntax to
> the xsd.
Yes, I can make another structs, and use them where I used replyof, but
not in reply - because struct generated for reply adds some fields
between first and second field ( these are sequence, and length ).
>> Don't you think that these fields could be
>> also replaced by fields of referenced structure ?
> They can be, except <list> only takes a single type. If it weren't for
> lists of structs, I might be arguing for the removal of structs, too.
>>> Every single piece of syntax you add is another piece of syntax that
>>> *every* generator must support. In particular, this one looks like a
>>> real pain to add to the Wireshark dissector (now on trunk -
>> Right, every time the syntax changes, every generator should be updated,
>> but it doesn't mean that syntax can't change. XKB needs syntax changes (
>> at least conditional tags ), so why not think about what tags/changes
>> are needed and feasible now ?
> I'm not arguing against adding necessary syntax. I agree that we need
> more syntax to support XKB and XI. I'm arguing against adding
> unnecessary syntax. Especially when it requires a streamy processor to
> keep even more state.
ok :) so replyof can be dropped, given that there will be 2 structs
holding same data - one defined by <reply> and one defined outside <reply>.
More information about the Xcb