NextPVR Web console to replace NEWA one day?

[mvallevand]

I use NEWA's web-services for a lot of nDroid via the nDroid Service which basically just acts as a proxy. It was a no-brainer Martin - developing Android apps to talk directly to .NET Web Services is a PITA and horribly slow and inefficient in real-world use.

Thanks for the clarification, I thought you might use NEWA too and would be impacted if sub removed it. For sure SOAP is not the best for the EPG data the 200 channels takes too a long time with x-newa on Android and also on low-end CPU linux machines like the RPi too but there seems to too many that solutions coming before there is a lot of discussion on how to best serve these platforms. It is not just the protocol though caching to SD card and internal NAND is quite a bottleneck, so maybe Plex got it right.

Martin

[stustunz]

I'm looking forward to your app

[reven]

Thanks for the clarification, I thought you might use NEWA too and would be impacted if sub removed it. For sure SOAP is not the best for the EPG data the 200 channels takes too a long time with x-newa on Android and also on low-end CPU linux machines like the RPi too but there seems to too many that solutions coming before there is a lot of discussion on how to best serve these platforms. It is not just the protocol though caching to SD card and internal NAND is quite a bottleneck, so maybe Plex got it right.

Martin

thats why any replacement for NEWA would have to be community supported and not replace NEWA over night. like i said not planning of even considering asking sub to replace NEWA for the next release, and most likely not even the release after that.

this API is completely open source and will be driven by the needs of the community. being restful/json/xml pretty much any language can easily talk to it and its low bandwidth (json + gzip == very small data, could even do bson to reduce bandwidth further).

basically the api works like

base url

Code:

http://server:port/api

guide stuff

Code:

http://server:port/api/guide?date=day&group=groupname

recordings

Code:

GET = http://server:port/api/recordings, returns a list of all available recordings for the user
GET = http://server:port/api/recordings/recordingoid, return actual recording instance
DELETE = http://server:port/api/recodings/recordingoid deletes single recording, if allowed to by user
DELETE= http://server:port/api/recordings/recurring/recurringoid, deletes recurring instance, if allowed to by user

etc, so its URL driven and everything returns a json/xml object (I need to add some serialization for some objects for xml output, but this is easy and I just havent gotten around to it yet).

i do need to test out some kinda authorization stuff, at moment web apps are easy since its just session stuff in asp.net with the cookies. it may work already, just havent tested on any platform other than mvc. but its still at an alpha stage and this is easy to add, so ill add it when needed in the beta.

Just so we're clear, I want this to replace NEWA, but not any time soon. and only if the community is behind it and agrees its a step forward and in the right direction.

I finally think we're getting somewhere, which is what i want this discussion to be about, an open and honest thing to clear the whole thing up

[mvallevand]

this API is completely open source and will be driven by the needs of the community. being restful/json/xml pretty much any language can easily talk to it and its low bandwidth (json + gzip == very small data, could even do bson to reduce bandwidth further).

I don't think bandwidth is the issue, these devices can stream HD afterall, it is parsing huge JSON, SOAP or TCP messages with the low powered CPU

Martin

[reven]

bandwidth is an issue on mobile devices, think scheduling a recording when you're not at home from you phone.

[mvallevand]

Scheduling only takes a few hundred bytes. What I was trying to get at was bgowland came up with solution for nDroid, X-NEWA caches SOAP as python pickles for XBMC, sub as always goes alone because he controls his side, and you and your community (which might include me one day) will offer another solution. Getting the EPG to get the event id that you need to schedule is the challenge, and it has nothing to do with JSON, SOAP, WSDL, it is a significant challenge that is certainly not addressed simply. The NEWA web service could easily send JSON gzip, bson or any message that Web Console can, but it doesn't address the fundamental issue, and I still haven't found one solid reason to think that Web Console provides a stronger backend for mobile clients than NEWA.

Martin

[reven]

There's no real reason for the web console to provide a better API than newa

But this API will support users, sending epg data is huge, talking megabytes in raw format. So bson could be very important for mobile clients. Newer tech just makes it easier to send multiple output formats from the same methods. WCF made it pretty easy to send Json or XML. Webapi makes it even easier and easier to work with with non .net languages like JavaScript

There's basically turn Apis, ones a wrapper for the core which the xbmc client talks to. This mimics subs API layer. And the full one off /API/.

My goal is just have a community driven API that everyone will hopefully use (then very client can get user support)

Written on iPhone so may have typos

[bgowland]

There's no evidence that using BSON is more efficient than JSON in every case - it all depends on the scenario (data types, number of records and so on) - it's "designed" to be more efficient but it doesn't always work out that way. Moreover, JSON is only slightly more efficient WRT file/data size than fully structured (formatted) XML in tests I've done but, again, depends on things like number of records and data types.

There are a number of aspects that contribute. The first is the efficiency of different libraries on different platforms used to generate and consume the data (e.g., libraries for C#, Java, iOS etc). The second, as Martin points out, is the capability of the mobile hardware (speed of mobile connection, speed of CPU, efficiency of saving to temp storage to decompress/parse EPG data etc).

In reality there will be a bottleneck somewhere but the main problem I have with any system which requires a "live" connection from mobile device is the inability to do certain things off-line such as browse/search the TV Guide.

[reven]

only thing im talking about is text encoding (json) to binary encoding (bson) binary would obviously provide a better bandwidth performance. sure it may be only a slight reduction in some cases, but still definitely worth looking into.

this isnt a BSON will replace JSON talk, the api will support JSON, XML and like BSON as well, its not one or the other. the data sent back will be exactly the same, it will just be wrapped differently depending on the "content-type" requested.

therse absolutely no reason why a mobile device cannot do things like a search offline, all you have to do is pass the EPG data to the client and on the client store it in a database (html5 has a database built in now, i was writing a jquery app for 4therecord which stored everything in the html5 db which worked just fine).

i personally wouldnt do a search offline, but theres not reason why it cannot be done. HTML5 and javascript are really powerful now.

[jksmurf]

I rarely use NEWA much through the browser, and I don't personally need multiple users Martin

Just an interested user perspective. I almost "exclusively" use NEWA, I do all my autorecords through it, works wonderfully and ... is ... simple and uncluttered. I don't use the css version so maybe I'm a neo-luddite in that respect, and like Martin I do not need multiple users, but I can see why some would. UJB has been great (and a constant) in fulfilling support requests and making most wishlist requests come true.

If needs must, and we do end up with an-singing all-dancing new web interface, then my greatest hope is that the same level of support remains a constant (granted, this is a hard-ask for what is a free plugin, but that's my wish all the same).

k.