thewbman at gmail
Mar 10, 2011, 10:02 AM
Post #7 of 13
I have a webOS app called WebMyth that uses the old XML calls (
Re: API Framework has been committed (May break existing users of mythXML).
[In reply to]
http://code.google.com/p/webmyth/) that will probably break some
functionality with this change. I do want to support both the old and new
versions in the app. Is there some easy way I could check to see if a
backend is using the old or new so my app could request the data
On Wed, Mar 9, 2011 at 9:26 AM, David Blain <MythTv [at] theblains> wrote:
> For those not following IRC, I committed the API Framework last night.
> A few things to note:
> *** THIS CHANGE MAY BREAK ANYONE USING OLD MYTHXML CALLS. ***
> In order to have a standard way to serialize objects, some of the data
> returned has been rearranged. Also, I took this opportunity to re-organize
> the methods and have separated them into these categories (each being its
> own API Class):
> Myth - Contains utility functions
> Guide - Program Guide Methods
> Dvr - Recording/tv related methods
> Content - Content Retrieval
> Myth - Yes, there are two services that use this... MythXml
> still has the GetInternetXXXX functions unchanged.
> ( the status page / status xml has not been changed at this time )
> How to access -
> Call each method using a URL formatted as:
> http://<backend>:6544/<API Class Name>/<Method>
> Methods default to responding to GET requests, however some have been
> configured to respond only to POST.
> (i.e. PutSetting will only work if called with a POST) Any method that
> modifies files/data should be limited to POST requests. This is done in
> service class definition.
> Parameters can be supplied on the query string, or as form post data
> (Content-Type: application/x-www-form-urlencoded).
> The code currently supports 3 data formats: XML, SOAP & json.
> XML - The default.
> SOAP - Returned if the request contains a SOAP envelope and required
> Json - Returned if the request header has an Accept value of
> Other formats can be implemented without changes to the API or Data
> Details -
> A new library has been added (libmythservicecontracts), which contains all
> the data classes and the abstract (pure virtual/interface) class
> for each of the API classes .
> Services -
> Each service class is defined as a pure virtual class. It must be derived
> from "Service", and declare the Q_OBJECT macro. It shouldn't have any
> implementation in it and should be treated solely as an Interface.
> this is not a requirement of the Framework, I chose this design to allow
> the creation of client proxy classes, (none have been created at this
> and can inherit from these base classes to provide a way to isolate the
> definition from the implementation.
> Each method can take any number/type of parameters. The parameter names
> used in the method prototype is what ultimately will be used when making
> service calls. Currently, only simple types are supported as parameters,
> but there are hooks in place to hopefully support complex parameters in the
> It is a requirement of each method to return a QObject* derived object, a
> pointer to a QFileInfo*, or a QVariant. If it's a QObject*, only
> declared using Q_PROPERTY will be serialized to the calling client.
> DataContracts -
> DataContracts are data classes designed specifically to be used to return
> complex data from service methods. They are currently contained in a DTC
> namespace to help with naming conflicts.
> There are numerous macros to help with the implementation. It's important
> that these classes only store data and do not offer any functionality. If
> one data class contains pointers to other data classes (an object
> hierarchy), each child object must be created with the current object as
> it's parent so that when the parent gets deleted, all it's children will as
> Implementation -
> The actual implement of all the service/api classes is currently in
> mythbackend (this may change in the future).
> The classes/methods can be freely used directly by any part of the
> application, so as the number of methods increase, duplicate functionality
> can be removed from other parts of the system.
> Here is an inventory of current methods:
> Base URL - http://mythbackend:6544/Myth/
> Methods -
> * These methods are still implemented in MythXml using legacy approach.
> Base URL - http://mythbackend:6544/Guide/
> Methods -
> Base URL - http://mythbackend:6544/Dvr/
> Methods -
> Base URL - http://mythbackend:6544/Content/
> Methods -
> I think this e-mail is long enough... let me know if you have any questions
> or find any issues.
> David Blain
> mythtv-dev mailing list
> mythtv-dev [at] mythtv