I came across this thread because I am interested in having a media server that hosts the whole library. In fact I was thinking that it would be interesting to have xbmc run in a 'thin client' mode, where all the catalogues, except for certain specific stuff (optical media), are hosted on the server. In many way I think it matters less how the implementation is done, than how the communication is done (protocol, formats, etc).
Plugins would be handled by the server for the most part, but it should not exclude client side plugins.
The way I see this working is that any add/update command would simply call the server and update it centrally, though I can imagine the case of a 'read-only' state. The server would also have a notion of user, to support the multi-user mode in xbmc. The server could also become a proxy for anything that doesn't handle networking by nature.
What I am thinking as the data format and protocol is simply HTTP and XML. The advantage being that you have a larger choice of platforms for implementation and it could provide different solutions to choose from. Possible implementations include Apache/PHP, Apache/Python, Tomcat/Java, etc. We can decide which implementation ends up being the better one once we have had a little competition
The only mandate I would put on the implementation is that it should be able to run on any platform where xbmc runs, so IIS/ASP or .net should be discouraged IMHO.
If this is an approach that is appealing, then the next task is simply to come up with an XML format that is suitable for each type of node. As to file encoding it would have to be UTF-8, simply so we don't end up in charset-hell, and anyhow all XML parsers should support it natively.
The node types I can think of are:
- modules node (describes a module)
- list node (a list of items)
- media node (the media we are interested in)
I would like to keep the number of node types down to a minimum, so that it reduces the implementation work load and to encourage people to reuse what is there.
All entries would support descriptive elements such as:
- media type
- description
- title
- preview image
- url
IMHO, while there should be a base list of elements, we should not exclude the possibility of adding extensions as new needs arise.
It may make sense to have the localisation of some of this content on the server.
The added benefit of using HTTP/XML is that with xslt you can actually render everything as HTML in a web browser.
Edit: I realise this approach may allow anyone to build an HTPC front-end to the media server, but it many ways that is a good thing. It gives a little competition and encourages people to focus on the developing elements where their strengths lie.