Posts: 379
Joined: Sep 2008
Reputation:
8
Please note, I'm not asking for a feature or suggesting ideas. I'm a developer and want to try my hand at some code hacking, but am not familiar with XBMC code base. All I know is there have been major changes in Eden, Frodo etc so I'm trying to get an idea of the effort involved in the following -
- library (probably built on db like MySQL) with client server or p2p model
- protocol to fetch/update metadata
- sync and sync conflict resolution with multiple clients of library
- extensible schema to support future updates easily
- all using open protocols, not sure how secure it needs to be
For all I know a lot of this already exists in some form or the other. I'm trying to get an idea if this is a massive undertaking or if I could get something going quickly. A lot would also depend on how modular relevant sections of the code currently are.
Posts: 26,215
Joined: Oct 2003
Reputation:
187
If you're a c/c++ dev, then one option is to just take XBMC and rip out anything you don't need, leaving JSON-RPC, UPnP server, Databases, VFS, scanner etc. Basically you'd be removing the GUI side of it.
This would certainly be something we'd be interested in, and I suspect you'll get a helping hand.
Your comment about how modular things are will be the key - much of XBMC is not particularly modular, though there is moves to change that (e.g. settings, which is the main tentacle monster (and relies on the GUI) is currently being overhauled by Montellese).
Cheers,
Jonathan
Posts: 17,859
Joined: Jul 2011
Reputation:
371
you might also wanna talk to topfs2 who is also thinking in your direction about having a small upnp/scraper/datas/json server app
Posts: 379
Joined: Sep 2008
Reputation:
8
Thanks, need to do some reading and I will at least get a code snapshot and start looking.
Posts: 31
Joined: Apr 2004
Reputation:
0
DesG
Junior Member
Posts: 31
I have been thinking about this recently.
The problem becomes how do you maintain it as one codebase.
The obvious answer is to split the system into two components a server component and a client. Those who only run a single machine have both components running on one machine, and those who want a distributed system have the server component running on the server, and the client component running on multiple clients.
Would that be feasible option for the XBMC team to think about as a way forward or would it need to be forked off as a completely separate project?
Cheers, Des.
Posts: 6,252
Joined: Jun 2009
Reputation:
115
da-anda
Team-Kodi Member
Posts: 6,252
There are plans that XBMC itself can work as both out of the box and communicate in some sort of mash mostly via UPNP and JSONRPC to sync stuff. So AFAIK there are no plans for separated client-server stuff, but rather a headless XBMC (no GUI) that can be used as server on f.e. a NAS.
Posts: 193
Joined: May 2010
Reputation:
0
i think i have a solution that will be ok with the issues that jmarshall brought up about the settings being tied to the GUI and ease the issue that DesG and da-anda discussed just above.
What if there was a command line switch that was setup to disable the GUI, kinda like the -p portable switch. so you can start the full fledged xbmc, to setup the settings/database/scanning sched/etc, then when everything is setup, you can start it with a -s switch or something, and that will start the "server" xbmc without GUI.
This should also allow the configuration of the "server" on you main workstation per se, then copy the setting to your NAS/server and run the -s, in case your server/nas cannot run the GUI due to video memory/resource limitations.
This will keep the code base the same, and only require the same hacks we would need anyway to make this a stand alone version, such as the "xbmc minified as a server" thread.