Archive:Google Summer of Code/2012

Project Proposals

Overview

Qualifications for a good Summer of Code proposal:

• Discrete, well-defined, modular
• Comprised of a series of measurable sub-goals
• Based on open specs that are available free of charge
• Based on complete specs

An example of a good proposal is the implementation of a new feature or function that is not yet available in XBMC.

An example of a less desirable proposal is one that's not as measurable, such as refactoring an existing API. Bad proposals tend to be ones that would require touching a lot of core code.

To re-iterate:

• Localized/isolated code projects = good
• Global code refactoring = bad

Students Project Proposals

Feel free to add ideas of projects here so it can be discussed further.

Input Generalization

Currently in XBMC input is handled very differently depending on the control and each input type is isolated and added as extra and the code have become quite a bit unmaintainable. This leads to a large number of regression bugs and a large number of inconsistencies between the input types. Some bugs are almost unfixable as it is really hard to follow what is going on and even harder to know what is supposed to go on.

As such I propose a clean general input layer where every input type is handled the same way and an input device is made up of a number of smaller, much easier to define, types of input.

The idea is the following: We have many input devices on the system, each input device have an ID which is used when mapping to an action. An ID is for example "wiiremote" or "mceremote". Ofcourse one could add that an input also have a UUID so multiple input devices of the same ID can exist and can be used in games, but this is another matter and the abstraction soon to be explained should be able to handle that addition. Each input device can send Input events to the Input manager, which resides in the core. An input event could for example be that a button is down/up or that a cursor have been moved to a new location. It can also state that an analog location have been moved. Further abstraction would be that an analog location is what a mouse cursor is, however it may make sense to separate those.

As it is currently in code a joystick button is not handled the same as a keyboard button or a remote button, not even a mousebutton. Essentially all button triggers should be processed in the same method and it does not really matter what input device triggered them.

For example a keyboard would be an input device with ID="keyboard" and could send that button="A" is down. Another input device could send ID="WiiRemote" and button="A" is down. Since ID is not the same these are not considered the same remote and the mapping can be different.

So every input on a system becomes an input device, each device can send input events which consist of the ID of the remote and information about the actual event. This event can reflect a button state change or a cursor change.

XBMC Core will then take the input event and map it depending on the ID and the actual event along with a window to create an action. This almost what is done now but currently the code is not general and not shared among the input types.

When we have a general input layer it would be possible to allow jsonrpc to act as an input but also create input addons.

Media Server

It becomes increasingly popular to have more than one instance of XBMC in a household, even more so with the introduction of XBMC on portable devices. This means that sharing the library between XBMC instances becomes much more important to the average user and the current model of doing this via MySQL, while it works, is not a user friendly solution nor future proof.

I propose that a project could be to take core features of XBMCs incredible media management and make them available in a seperate server instance. Note that this does not enforce a client server model and I am not proposing a move to a client server solution, XBMC will should always have the possibility to run as a stand alone instance fully in charge of its data, this is one of the most important features which most other media centers does not have and it makes XBMC a very user friendly application. What I am proposing is merely the possibility to have XBMC act more like a thin client, i.e. if a server exist on the network its transparently added and feels like it is integrated in client.

Instead of doing the sharing over MySQL the data could be shared over uPnP, afterall uPnP is made to share libraries. This would also make other media devices, which is not power by XBMC, able to use said features. The features which makes XBMCs media playback and presentation so great are amongst other things our VFS and scrapers, coincidentilly these parts of XBMC are those which have had quite a bit of feature creep and could use some sanitizing. What I propose is to create small isolated libraries, tested and designed outside of xbmc. The media server would thus be a way to actively test the libraries and hopefully spot problems in the API before they get adopted. When the libraries are considered in a clean state they could be used inside XBMC aswell (not part of this proposal though). The code which is sane in XBMC can obviously be ported over, no need to reinvent the wheel. This does allow for an interesting possibility to clean up our API and make these features available for more than just XBMC with the nice sideeffect of creating a media server!

This proposal should focus on creating a sane API for the libraries which could be used in XBMC (and any other application) later on, the media server will act as a testbed for said libraries. The important part of this proposal is not creating the best media server and not really the most implemented libraries but to create clean, reusable libraries for xbmc or any other application, this way its not only media server users which would benefit.

The media server would use uPnP for sharing and should be modeled much like how transmission and deluge are, where the core is a service which can be run by user or by system. The GUI is connected and gets its data over sockets and makes it easy to add new GUIs such as GTK, KDE, CLI or any other platform like windows or OSX. I propose to use XBMC JSON-RPC specification as its not extremely bound to XBMC and this could prove to clean up that interface aswell and make it more just an API for any media manager / media player. This would also allow remote controls like android remote to connect to just the server and XBMC users could gain another usage of the technologies.