Kodi Community Forum
Unified PVR frontend (DVR/HTPC client GUI with EPG) and Addons API for PVR backends? - Printable Version

+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Development (https://forum.kodi.tv/forumdisplay.php?fid=32)
+--- Forum: Add-ons (https://forum.kodi.tv/forumdisplay.php?fid=26)
+---- Forum: PVR (https://forum.kodi.tv/forumdisplay.php?fid=136)
+---- Thread: Unified PVR frontend (DVR/HTPC client GUI with EPG) and Addons API for PVR backends? (/showthread.php?tid=28918)

Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19


- SSchocke - 2009-01-19

alcoheca Wrote:Maintaining multiple clients inside XBMC source tree is sub-optimal and would only end up with stale code and unwanted support requests when plugin developers stop maintaining them. It's not that much hassle to switch to packaging the clients once the API is finalized so I don't see the issue.

While I agree with you that it is bad to have the stale packages inside the XBMC source tree, another issue came to mind. If we package the client plugins outside of the XBMC source code, client developers would lose all the nifty cross-platform utility classes and functions available inside the XBMC source tree. Eek

AFAIK, and correct me if I am wrong here, all those classes and functions get compiled straight into the executable, so it's not possible to link the client against it. Developers would have to copy those classes out of the XBMC source tree to replicate their functionality, or the utility classes/functions would have to be moved out to a library. Shocked

If you have a way of working past all this, I would be very happy to learn how Nerd


- alcoheca - 2009-01-20

In another thread the possibility of exposing access to the SQL functionality in CTVDatabase (for clients that would have to cache the EPG) was mentioned (by me) but there wasn't much discussion on it. Having a SQL interface at your command seems like a lot of sense to me for problematic backends/situations, and I'm sure there are strong cases for other utility classes (DateTime maybe?) to be exposed.


- SSchocke - 2009-01-20

Has there been any talk about perhaps moving the utility classes out into a separate library by the XBMC Dev Team?


- jmarshall - 2009-01-20

Which ones would you want?


- splat1 - 2009-01-21

@ alcoheca.
Just a post to say managed to compile and get it running, seems to be running as expected hope to see more Smile

Linux mediacentre 2.6.24-23-generic #1 SMP
mythbuntu

Might give building under OSX10.5 a go when I get some free time.


- SSchocke - 2009-01-21

jmarshall Wrote:Which ones would you want?

Rofl Do you want to make a list alcoheca, or should I? Wink

Seriously though, there are a few classes which I think will be critical. CURL jumps to mind. CFileItem*, CSingleLock, CCriticalSection, CThread, CDateTime, CDateTimeSpan, CStdString (could be worked around by using std:Confusedtring), CLog.

The SQLite interface, and Configuration settings would be nice to have as well, but by no means necessary.

I am sure alcoheca could come up with a few more. At the end of the day we could work around all this by creating our own structures based on primitives, passing these back from the clients to the PVRManager, and having PVRManager create the required XBMC structures. It just seems simpler to use the already created(and cross platform tested) XBMC classes than re-inventing the wheel.


- alcoheca - 2009-01-21

SSchocke Wrote:Seriously though, there are a few classes which I think will be critical. CURL jumps to mind. CFileItem*, CSingleLock, CCriticalSection, CThread, CDateTime, CDateTimeSpan, CStdString (could be worked around by using std:Confusedtring), CLog.

The SQLite interface, and Configuration settings would be nice to have as well, but by no means necessary.

CFileItem has multiple dependencies - I don't think this is feasible or even wanted. What do you need it for?

I think it may be smarter to do all recording of settings and logging through CPVRManager.

The rest are largely separate and are worth considering, particularly the threading classes.


- SSchocke - 2009-01-21

Was just roughly going by a list of the classes used in the current MythTV client, and classes that I have found useful. I agree about CFileItem. It doesn't provide any needed functionality, but it was used in MythTV PVRClient, so I added it. Huh

I do however disagree about the logging. We could manage it via PVRManager, but it would be better if it was moved to the proposed library. Then other people developing something that ties into XBMC have the provided functionality already. If CLog exposes too much functionality to the outside world, create a CExLog (External Log) class inheriting from CLog that hides all the functionality except writing to the log file.

All in all, I wasn't really looking at the util lib as something only to be used by the PVR Clients, but rather a start at making it possible for other software to tie into the XBMC environment as well.

But, by all means, I am new here, and have no idea what I am talking about, so please feel free to correct me Nod


- alcoheca - 2009-01-21

Cool, just checking about CFileItem. Smile

You're right we should be thinking about the util lib being used above and beyond the pvr clients. CExLog sounds like a good idea.

How much do you know about creating a lib then? I have next to no experience of any of this.


- SSchocke - 2009-01-21

alcoheca Wrote:How much do you know about creating a lib then? I have next to no experience of any of this.

On windows side it should be very simple. I have not done it in C++ in a while, but basically create a lib, move the files there, make sure XBMC project can still see the header files, and tell XBMC to link against the lib.

Same thing on Linux. Have done it there as well, but many moons ago, and nothing as huge or complex as the XBMC project. My makefile's were mostly handcoded and 20 lines long or so.

Also, I have not really had a look at XBMC's DllLoader concept. I understand the need for it, but does it even apply to the util lib. Does it apply to the guilib?

If approved, I would not mind taking a quick detour and trying to make a util lib with a few key classes and getting it to work, but would need some help with the DllLoader business.


- SSchocke - 2009-01-21

OK... after a brief bit of experimentation, it seems this will be way harder than anticipated. Even the simplest of classes (CURL, CDateTime) all in some way or another link back to the CFile, which means the whole CFile* range of classes get pulled in. A BIG problem seems to be the CUtil class, which pulls in so many headers, it looks more like all the functions seem to have been bundled into one file, from simple StdString functions, to SDL stuff, network protocols, player cores, FTP stuff and GUI functions. Eek

In short, moving any of these classes out of the XBMC source is going to be lots of hard work!!! Sad


- alcoheca - 2009-01-21

Aye CUtil pulls in crap-loads.

Bit of a bummer then... Sad

The three threading related classes look like better candidates, and I'm thinking that we should aim to guarantee that each client has it's own thread to ward against buggy client code. So maybe that's as simple as having IPVRClient inherit CThread.

Building wise, it would be great if Windows compiled plugins would work on Xbox. Linux and OSX would be two seperate builds?

I wonder how we can make things easier for developers to release for all platforms.


- jmarshall - 2009-01-22

We'd have no problem if you were to undertake such work. CUtil in particular is a dumping ground for many, many things, much of which could do with a good refactor.

We have StringUtils for instance for string based stuff.

Cheers,
Jonathan


- SSchocke - 2009-01-22

alcoheca Wrote:The three threading related classes look like better candidates, and I'm thinking that we should aim to guarantee that each client has it's own thread to ward against buggy client code. So maybe that's as simple as having IPVRClient inherit CThread.

Will have a look at them when I get home tonight

jmarshall Wrote:We'd have no problem if you were to undertake such work. CUtil in particular is a dumping ground for many, many things, much of which could do with a good refactor.

We have StringUtils for instance for string based stuff.

Great Smile I think I am going to take the path of trying to "Categorize" the functions and classes more. Like StringUtils, FileUtils, URLUtils, etc. and building up the classes on top of those afterwards. Perhaps also create a couple of Interfaces with no functionality and let XBMC internals implement those interfaces instead of whole classes in the util lib for File, Network and System related functions. Then the util functions can still receive parameters with internal XBMC data structures, without having to implement them Big Grin


- SSchocke - 2009-01-23

NoNoNo

This stuff is so convoluted and dependent on each other, it's going to take a day and a year, not mentioning moving over 80% of the stuff over just to make CDateTime work. (CDateTime provides regional formatting, regions get loaded in from XML, which region gets loaded is handled via settings file, settings files use CFile, all of which gets loaded into global variables in XBMC source.)

Pretty much anything else uses CLog. CLog SHOULD NOT be a problem, but it also relies on the settings file, not to mention, it relies on Path Translation functions from CUtil, which rely on IOSupport functions, which relies on Media Detection routines, which relies on .....

I'm sorry, but I just find this fundamentally wrong Confused. The logging functionality of an application should by definition not rely on anything to be in place. As it stands, an improperly formatted settings file breaks the entire applications logging facility. A problem detecting which media XBMC is running from breaks the logging.

I am not saying determining a valid logging location (LiveCD, multi-platform obviously has special needs in this regard), I am just saying it should not be the CLog class that determines it.

As a starting point, I am going to see if I can rewrite the CLog class to simply do the logging, and move the initialization out to CApplication or so.

Also, coming back to an earlier question... Static vs Dynamic library. I noticed that all the existing libraries (like guilib) are statically linked into XBMC. I need to setup a test application in this regard, but maybe somebody can give me a quick answer.

If I have static library A, and I statically link it into Application B and Application C, and I have a global variable X defined in A, and I change X in App B, does App C also see the update, or does B and C create their own copy of the X variable in memory?

If each creates it's own copy, using static libraries to create a interface to XBMC seems impossible. And I still have no idea how the DllLoader concept works, and if it would be possible to use it to load in the util lib which would host so many of the fundamental classes and functions required to initialize the application Huh

Sorry for the long rant... Had to get it out of my system... Short version is HELP Rolleyes