[mythtv] Looking to commit code...

[David Blain]

> There's no need to relocate the enums unless people really want to. 
> Also, wouldn't you be introducing a circular dependancy? The recording 
> classes would depend on the serializing classes for enums but the 
> serializing classes would depend on the recording classes for parameter
types.

No, I'm talking about moving the enums to the Data Contract classes (not the
serialization classes).  That is where they must be defined for them to work
with Qt's metadata functions and it's a logical place to have them.

> It's easy to wrap macros around whatever enums are needed and have 
> them declared in multiple places and that takes care of the out-of-sync
issue. 
> It shouldn't take me very long to disentangle my macros from my QMeta* 
> adventuring and I can have a patch ready shortly.

I don't like having multiple of the same enum's defined even if wrapped in a
macro.  There should only be one place that defines them.

> Will your serializing code handle bitmask fields like recording.videoProps
and 
> audioProps? That's what got me into this in the first place. I think it
makes sense 
> to have bitmasks go out as maps where the enum symbols are keys and the
values 
> are booleans.

Bitmasks would be more difficult but not impossible.  I would need to
research what the standard is for a bitmask.  The main goal is allowing
different systems to interact using standard protocols.  So I wouldn't want
to use a custom serialization technique if it broke compatibility with other
systems.

David.