[Xcb] GSoC 2009: XKB and XI2 support

[Mariusz Ceier]

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 -
>>> http://anonsvn.wireshark.org/viewvc/trunk/tools/process-x11-xcb.pl?view=markup&pathrev=29871
>>> ).
>> 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>.

Mariusz Ceier