Mailing List Archive: MythTV: Dev

Looking to commit code...

Index | Next | Previous | View Threaded

mythtv at theblains

Mar 5, 2012, 12:33 PM

Post #1 of 10 (521 views)
Permalink

Looking to commit code...

All,

Guess I'm a little late to the party since Beta 1 has been packaged up!

I have three sets of commits I'd like to make, but since it's so late in the
release cycle I figured I'd ask here before proceeding.

Commit #1 - Fix for DataDirect

For some reason, my firewall un-gzips the response from DD prior to sending
it to mythfilldatabase. The patch I have simply checks for a 0 unzip length
and uses the original downloaded data.

Commit #2 - VS2010 tweaks

I missed two small changes to allow code to be compiled in Visual Studio
2010.

Commit #3 - Fix for WSDL generation.

Main bullet points:

* Generates individual Schema (xsd) files on request.
* Added xslt templates tied to the WSDL & XSD files so they "Pretty Print"
when accessed in a browser.
* Tested using C#, able to generate all proxy classes. Tested calls from
Win7 / C# app successfully.
* NOTE: Had to change the way QVariantMap is serialized to XML. Key is no
longer an attribute. Now it's an element. I would prefer this going in now
so we can keep the interface to the Services API fairly stable (would hate
to have to change the schema post 0.25). Also, not many people should be
using this interface yet.

I can provide patches if anyone wants to review.

Please let me know if I can proceed with committing these changes.

Thanks,

David.

_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

gnassas at mac

Mar 6, 2012, 5:38 AM

Post #2 of 10 (499 views)
Permalink

Re: Looking to commit code... [In reply to]

On 2012-03-05, at 3:33 PM, David Blain wrote:

> NOTE: Had to change the way QVariantMap is serialized to XML. Key is no
> longer an attribute. Now it's an element. I would prefer this going in now
> so we can keep the interface to the Services API fairly stable (would hate
> to have to change the schema post 0.25). Also, not many people should be
> using this interface yet.

Kind of in the same vein are bitmask properties like recording video and audio properties. Right now a raw integer is written which is a pain to interpret. You'd expect the json to look like this:

VideoProps:
{
VID_DAMAGED : false,
VID_1080 : true,
...
}

Same deal for enums: a recording's status is written as an integer where you'd expect to see "rsRecorded" etc.

Is the bitmask thing intentional? Slip through the cracks?

If you give a hint for how to implement it I could whip up a patch assuming that such changes are welcome at this late stage.

- George

mythtv at theblains

Mar 6, 2012, 2:00 PM

Post #3 of 10 (493 views)
Permalink

Re: Looking to commit code... [In reply to]

> Kind of in the same vein are bitmask properties like recording video and
> audio properties. Right now a raw integer is written which is a pain to
interpret.
> You'd expect the json to look like this:
>
> VideoProps:
> {
> VID_DAMAGED : false,
> VID_1080 : true,
> ...
> }
>
> Same deal for enums: a recording's status is written as an integer where
> you'd expect to see "rsRecorded" etc.
>
> Is the bitmask thing intentional? Slip through the cracks?
>
> If you give a hint for how to implement it I could whip up a patch
assuming
> that such changes are welcome at this late stage.
>
> - George

The serialization library is written to be generic with no knowledge of the
data being serialized other than that provided by Qt's metadata.

Although Qt does have a way to identify enums (using the Q_ENUM macro), I
hit a snag using it. It requires that the enums be part of the class using
the macro and this class needs to be derived from QObject.

Since we're using enums that are defined in the global namespace located in
other libraries, the Q_ENUM macro doesn't work. I looked into two options:

1) Make duplicate enums in the Service/Data Contract classes (too likely to
get out of sync).
2) Move enums to Service/Data Contract classes. (This would need a large
refactoring of the current code base... not something I was willing to take
on at this point)

If you can find a solution to this, I'd be more than happy to review/commit
the patch.

David.

_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

gnassas at mac

Mar 7, 2012, 9:24 PM

Post #4 of 10 (480 views)
Permalink

Re: Looking to commit code... [In reply to]

On 2012-03-06, at 5:00 PM, David Blain wrote:

> I looked into two options:
>
> 1) Make duplicate enums in the Service/Data Contract classes (too likely to
> get out of sync).
> 2) Move enums to Service/Data Contract classes. (This would need a large
> refactoring of the current code base... not something I was willing to take
> on at this point)
>
> If you can find a solution to this, I'd be more than happy to review/commit
> the patch.

I agree about the shortcomings so I started wondering about exploring either of two notions:

- defining enums through some kind of funky dual-purpose macros that can do the definition and create serializer structures based on context
- parsing header files and generating text/value arrays as output

and before I had to do any further thinking I found a page (http://stackoverflow.com/questions/201593) at the most helpful site on the web.

I like the gccxml approach since it's non-invasive and it's easy to add new enums once some generic xsl is written.

Probably the main question is how do people feel about adding a new build dependancy? I'm sure gccxml is packaged for all the linux distros & BSD but I'm not sure about Mac and Windows. On the other hand I notice the MacPorts port file doesn't show any dependencies so maybe it's a painless thing to add.

- George
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

gjhurlbu at gmail

Mar 8, 2012, 12:03 AM

Post #5 of 10 (478 views)
Permalink

Re: Looking to commit code... [In reply to]

On Wed, Mar 7, 2012 at 9:24 PM, George Nassas <gnassas [at] mac> wrote:
> - defining enums through some kind of funky dual-purpose macros that can do the definition and create serializer structures based on context

I would go for this option, personally. We already have a similar
concept for verbose definitions. It's actually rather easy to do once
you've figured it out :)

I don't think we really want yet another tool just for the sake of
making it "simple" when we may not be supported on all our platforms.

Just my thoughts.
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

gnassas at mac

Mar 8, 2012, 9:12 AM

Post #6 of 10 (467 views)
Permalink

Re: Looking to commit code... [In reply to]

On 2012-03-08, at 3:03 AM, Gavin Hurlbut wrote:

> On Wed, Mar 7, 2012 at 9:24 PM, George Nassas <gnassas [at] mac> wrote:
>> - defining enums through some kind of funky dual-purpose macros
>
> I would go for this option, personally

OK, it doesn't sound too difficult. Clearing some free time on the other hand... hopefully on the weekend.

- George

_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

gnassas at mac

Mar 26, 2012, 2:30 PM

Post #7 of 10 (388 views)
Permalink

Re: Looking to commit code... [In reply to]

On 2012-03-06, at 5:00 PM, David Blain wrote:

> The serialization library is written to be generic with no knowledge of the
> data being serialized other than that provided by Qt's metadata.
>
> Although Qt does have a way to identify enums (using the Q_ENUM macro), I
> hit a snag using it. It requires that the enums be part of the class using
> the macro and this class needs to be derived from QObject.

Hi David, off and on over the past few weeks I have poked around with serializing enums but can't seem to get it to work.

From what you wrote above I interpreted that if you define an enum inside a service/data contract class and declare it with Q_ENUM then the serializer would write the enum symbol instead of a numeric value but that doesn't happen. You still get an integer.

I thrashed around with different approaches such as trying Q_DECLARE_METATYPE() and qRegisterMetaTypeStreamOperators<MyClass>("MyClass") but as you might guess they're for classes not enums. I forget what else I tried but nothing worked.

When I get another chance I'll try a small standalone program & explore but I wanted to post briefly in case you or someone else has any insights. It would be embarrassing if I missed something obvious but at this point I'd rather have it work than look brilliant.

For what it's worth it's trivial to write macros to dual-declare enums. I just don't get how to work them into Qt.

- George
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

MythTv at Theblains

Mar 26, 2012, 3:25 PM

Post #8 of 10 (388 views)
Permalink

Re: Looking to commit code... [In reply to]

> From what you wrote above I interpreted that if you define an
> enum inside a service/data contract class and declare it with
> Q_ENUM then the serializer would write the enum symbol instead
> of a numeric value but that doesn't happen. You still get an integer.

I guess I should have been clearer... I played with using Q_ENUM to print
the enum name, but since I couldn't get it to use existing enums defined in
core libraries, I never finished the serialization code to property support
them.

If everyone agrees to re-locate the enums, I would be happy to add the
needed code to the serialization classes.

Sorry for any confusion,

David.

_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

gnassas at mac

Mar 26, 2012, 6:43 PM

Post #9 of 10 (388 views)
Permalink

Re: Looking to commit code... [In reply to]

On 2012-03-26, at 6:25 PM, David Blain wrote:

> If everyone agrees to re-locate the enums, I would be happy to add the
> needed code to the serialization classes.

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.

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.

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.

- George

MythTv at Theblains

Mar 26, 2012, 7:23 PM

Post #10 of 10 (384 views)
Permalink

Re: Looking to commit code... [In reply to]

> 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.

_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads