[mythtv] json vs XML
Joseph Mills
josephjamesmills at ubuntu.com
Sat Aug 17 14:28:03 UTC 2013
I for one would hate to see the api just switched over to pure json. As
there are many their party apps that use json. Maybe if there was a way to
call the one you want to use example. Http://<yourbackend>:6544/foo?type=XML
Or
Http://<yourbackend>:6544/foo?type=json
Just a thought
On Aug 17, 2013 8:00 AM, <mythtv-dev-request at mythtv.org> wrote:
> Send mythtv-dev mailing list submissions to
> mythtv-dev at mythtv.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://www.mythtv.org/mailman/listinfo/mythtv-dev
> or, via email, send a message with subject or body 'help' to
> mythtv-dev-request at mythtv.org
>
> You can reach the person managing the list at
> mythtv-dev-owner at mythtv.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of mythtv-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: Ticket #11752: Recordings may end up in live tv group
> (Joseph Fry)
> 2. Re: Ticket #11752: Recordings may end up in live tv group
> (Michael T. Dean)
> 3. Re: [mythtv-commits] Ticket #11753: Dvr/AddRecordSchedule
> does not work (George Nassas)
> 4. Re: [mythtv-commits] Ticket #11753: Dvr/AddRecordSchedule
> does not work (MythTV Dev Tikinou)
> 5. Re: [mythtv-commits] Ticket #11753: Dvr/AddRecordSchedule
> does not work (George Nassas)
> 6. Re: [mythtv-commits] Ticket #11753: Dvr/AddRecordSchedule
> does not work (Bill Meek)
> 7. Re: [mythtv-commits] Ticket #11753: Dvr/AddRecordSchedule
> does not work (MythTV Dev Tikinou)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 16 Aug 2013 09:57:09 -0400
> From: Joseph Fry <joe at thefrys.com>
> To: Development of MythTV <mythtv-dev at mythtv.org>
> Subject: Re: [mythtv] Ticket #11752: Recordings may end up in live tv
> group
> Message-ID:
> <CAAJE3SsPL=
> UxGtOC+ooMD7xNgmmfaMA1EXdTd6HE4XaUJ+UqiA at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> > And, FWIW, there are very few reasons to ever define a Live TV Storage
> Group
> > (and the only case where it makes sense is a less-than-ideal
> system/storage
> > configuration--so I don't know of any good reasons to define it). Not
> > defining a Live TV Storage Group allows MythTV to decide the most-ideal
> > location to store the new recording, according to the same Storage Group
> > Disk Scheduler selected for use with recordings. And, for those who
> believe
> > that having a dedicated partition for Live TV is better to prevent
> expiring
> > something they want, dedicating space to only Live TV only reduced the
> > amount of space available for storing recordings.
> >
> > Unfortunately, though, mythtv-setup makes users think it's a good thing
> to
> > define the group by having a button specifically to create the group.
> Users
> > see that and think, "I want to use Live TV," so they think they
> should/must
> > create the group.
> >
> > We may want to consider doing less to encourage users to create a Live TV
> > Storage Group--such as removing the button in mythtv-setup "(Create Live
> TV
> > group)". Also, it makes sense to encourage distro packagers to stop
> > creating Live TV Storage Groups for users.
>
>
> I completely disagree. I use Live-TV storage groups religiously. If
> LiveTV is not in the same SG as my recordings, I can choose to backup
> just the recordings I care about, I can chose to RAID just my
> recordings, etc.
>
> Additionally, I created whats essentially a "WAF" storage group...
> containing shows that, if lost, might shorten my life expectancy. The
> folders in this SG are rsynced to a separate machine for live backup.
> Additionally I have a cron that notifies me of any recordings that are
> too small to be useful videos so that I can try and remedy the
> situation before the wife notices.
>
> Storage groups are a very handy tool...and being able to create more
> of them to suit your needs is what makes them so great.
>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 16 Aug 2013 11:10:18 -0400
> From: "Michael T. Dean" <mtdean at thirdcontact.com>
> To: Development of MythTV <mythtv-dev at mythtv.org>
> Subject: Re: [mythtv] Ticket #11752: Recordings may end up in live tv
> group
> Message-ID: <520E40DA.1040702 at thirdcontact.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 08/16/2013 09:57 AM, Joseph Fry wrote:
> >> And, FWIW, there are very few reasons to ever define a Live TV Storage
> Group
> >> (and the only case where it makes sense is a less-than-ideal
> system/storage
> >> configuration--so I don't know of any good reasons to define it). Not
> >> defining a Live TV Storage Group allows MythTV to decide the most-ideal
> >> location to store the new recording, according to the same Storage Group
> >> Disk Scheduler selected for use with recordings. And, for those who
> believe
> >> that having a dedicated partition for Live TV is better to prevent
> expiring
> >> something they want, dedicating space to only Live TV only reduced the
> >> amount of space available for storing recordings.
> >>
> >> Unfortunately, though, mythtv-setup makes users think it's a good thing
> to
> >> define the group by having a button specifically to create the group.
> Users
> >> see that and think, "I want to use Live TV," so they think they
> should/must
> >> create the group.
> >>
> >> We may want to consider doing less to encourage users to create a Live
> TV
> >> Storage Group--such as removing the button in mythtv-setup "(Create
> Live TV
> >> group)". Also, it makes sense to encourage distro packagers to stop
> >> creating Live TV Storage Groups for users.
> >
> > I completely disagree. I use Live-TV storage groups religiously. If
> > LiveTV is not in the same SG as my recordings, I can choose to backup
> > just the recordings I care about, I can chose to RAID just my
> > recordings, etc.
> >
> > Additionally, I created whats essentially a "WAF" storage group...
> > containing shows that, if lost, might shorten my life expectancy. The
> > folders in this SG are rsynced to a separate machine for live backup.
> > Additionally I have a cron that notifies me of any recordings that are
> > too small to be useful videos so that I can try and remedy the
> > situation before the wife notices.
> >
> > Storage groups are a very handy tool...and being able to create more
> > of them to suit your needs is what makes them so great.
>
> I only said we need to stop encouraging users to create this one. For
> 99% of users having a Live TV Storage Group defined does nothing
> useful--and actually probably reduces functionality. I didn't say
> anything about removing the ability to create a Live TV SG, I'm only
> trying to make it so that users don't do it *unless they have good
> reason to*.
>
> Mike
>
>
> ------------------------------
>
> Message: 3
> Date: Fri, 16 Aug 2013 19:18:39 -0400
> From: George Nassas <gnassas at mac.com>
> To: "mythtv-dev at mythtv.org" <mythtv-dev at mythtv.org>
> Subject: Re: [mythtv] [mythtv-commits] Ticket #11753:
> Dvr/AddRecordSchedule does not work
> Message-ID: <74F27970-FC70-478B-AF64-BD9B5A86F168 at mac.com>
> Content-Type: text/plain; charset=us-ascii
>
> > Comment (by gigem):
> >
> > The services API is still very immature and subject to change between
> > MythTV versions.
>
> Sure but there's no reason to make it difficult for clients to know what
> they're dealing with. Currently getting the API version is arcane with XML
> and impossible with JSON. Seems like something which ought to be there on
> day one.
>
> - George
>
> ------------------------------
>
> Message: 4
> Date: Fri, 16 Aug 2013 19:35:56 -0400
> From: MythTV Dev Tikinou <mythtv-dev at tikinou.com>
> To: Development of MythTV <mythtv-dev at mythtv.org>
> Subject: Re: [mythtv] [mythtv-commits] Ticket #11753:
> Dvr/AddRecordSchedule does not work
> Message-ID:
> <CA+B8Lz6EAU9-aek7Fn_HezA4-S5jT=
> kgH7_NE0m8gZy_DjOo0A at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Aug 16, 2013 7:19 PM, "George Nassas" <gnassas at mac.com> wrote:
> >
> > > Comment (by gigem):
> > >
> > > The services API is still very immature and subject to change between
> > > MythTV versions.
> >
> > Sure but there's no reason to make it difficult for clients to know what
> they're dealing with. Currently getting the API version is arcane with XML
> and impossible with JSON. Seems like something which ought to be there on
> day one.
> >
> > - George
> > _______________________________________________
> > mythtv-dev mailing list
> > mythtv-dev at mythtv.org
> > http://www.mythtv.org/mailman/listinfo/mythtv-dev
>
> In order to deal with this (and granted I know that endpoint version !=
> backend version) I created a couple of things in a mythtv service api java
> library ( https://github.com/MythTV-Clients/MythTV-Service-API) first the
> code is generated from the wsdl, and second it checks the backend version
> by using the http headers. I know that this is not ideal however I
> certainly understand that this is a system only deployed on someone's LAN
> and not a amazon/google style service accessible by the entire world. Is it
> perfect? Certainly not; i ended up changing my app so that it is fully
> isolated from myth changes.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://www.mythtv.org/pipermail/mythtv-dev/attachments/20130816/f85b8469/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 5
> Date: Fri, 16 Aug 2013 21:19:46 -0400
> From: George Nassas <gnassas at mac.com>
> To: Development of MythTV <mythtv-dev at mythtv.org>
> Subject: Re: [mythtv] [mythtv-commits] Ticket #11753:
> Dvr/AddRecordSchedule does not work
> Message-ID: <9B154C28-0CE0-4D6C-B669-AF93361FB4BE at mac.com>
> Content-Type: text/plain; charset="windows-1252"
>
> On 2013-08-16, at 7:35 PM, MythTV Dev Tikinou wrote:
> > first the code is generated from the wsdl, and second it checks the
> backend version by using the http headers
> >
> Good idea, I was thinking of probing by calling changed apis and seeing if
> I got an unknown command error or missing parameters. Besides what you?re
> doing you can also get an api version from the third word of the wsdl?s
> definitions/services/description but you?re parsing conversational text so
> it could change on a whim and also json clients are totally SOL.
>
> I mean, whoever thought up the myth protocol figured out how to implement
> a monotonically increasing integer and so did whoever designed the database
> schema layer and they both put their integers in easy to find places.
> Somehow that technology didn?t make it into the services api which is odd
> as it?s a pretty complete and useful api for the areas it covers.
>
> So c?mon guys, how 'bout one more api call? /Myth/GetAPIVersion
>
> - George
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://www.mythtv.org/pipermail/mythtv-dev/attachments/20130816/af312e36/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 6
> Date: Fri, 16 Aug 2013 21:13:44 -0500
> From: Bill Meek <keemllib at gmail.com>
> To: mythtv-dev at mythtv.org
> Subject: Re: [mythtv] [mythtv-commits] Ticket #11753:
> Dvr/AddRecordSchedule does not work
> Message-ID: <520EDC58.4020009 at gmail.com>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> On 08/16/2013 08:19 PM, George Nassas wrote:
> ...
> > So c?mon guys, how 'bout one more api call? /Myth/GetAPIVersion
>
> Hi;
>
> Or add to the existing: <MBE hostname>:6544/Myth/GetConnectionInfo
>
> <ConnectionInfo version="1.1" serializerVersion="1.1">
> <Version>
> <Version>v0.27-alpha-183-g3fca292</Version>
> <Branch>master</Branch>
> <Protocol>77</Protocol>
> <Binary>0.27.20130814-1</Binary>
> <Schema>1315</Schema>
> </Version>
> ...
>
> --
> Bill
>
>
> ------------------------------
>
> Message: 7
> Date: Fri, 16 Aug 2013 22:23:31 -0400
> From: MythTV Dev Tikinou <mythtv-dev at tikinou.com>
> To: Development of MythTV <mythtv-dev at mythtv.org>
> Subject: Re: [mythtv] [mythtv-commits] Ticket #11753:
> Dvr/AddRecordSchedule does not work
> Message-ID:
> <CA+B8Lz6==
> NxjvwzxowkbRpPO31AbH8O6iOpNyYyW2SqhawuX+g at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> The only issue is that the service api doesn't fall into one version,
> each endpoint has its own version, so you would have to query the
> version of each endpoint.
> I can provide a patch that would provide a new method to the Myth
> endpoint which would take an endpoint name and query its version.
> Now I highly doubt that this would make it to 0.27, I did a patch for
> expose the markup/commskip data a couple of months ago, it was
> accepted but hasn't made it to 0.27...
>
>
> ------------------------------
>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
> http://www.mythtv.org/mailman/listinfo/mythtv-dev
>
> End of mythtv-dev Digest, Vol 126, Issue 10
> *******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mythtv.org/pipermail/mythtv-dev/attachments/20130817/476bf2cc/attachment.html>
More information about the mythtv-dev
mailing list