Archive:Google Summer of Code/2012

From Official Kodi Wiki
Revision as of 23:29, 10 March 2011 by >Topfs2 (→‎Media Server)
Jump to navigation Jump to search

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
  • A project should have a set of subgoals, so even if the end goal turns out to be to big some of the parts will be of benefit.
  • Not to big! This is an important problem when choosing a project, while it is fun to think about solving a grand project its not always realistic. Its better to finish a smaller project than to start a grand one.

Skeleton for proposals

Some project title

  • Summary: A somewhat small but explanatory walk through of the project. It should not be overly detailed just enough to understand the problem trying to be fixed and how this project opt to solve it.
  • What will the project focus on: Explain what the project will be about in more detail, how do you plan to achieve the project.
  • Benefits: Who will benefit and why from this project. Think about what a user or developer may need or do to benefit from it. Why does it benefit many users.
  • Goals: What is the goal of the project, a project may not always solve the problem entirely as it may take to much time. Think hard about what can be accomplished during a summer with your skill and deduct that quite a bit. If the project can't be done after this perhaps its better to opt for a smaller one or one with subgoals.
  • What does it touch in XBMC: Think about what parts of the code this may touch, XBMC is a big application and a lot of the code is spread out and very complex. If a project touches to much it may be impossible to complete.
  • Requirements: What is needed to complete the project, what code language knowledge what hardware etc.
  • Possible mentors: Place to add possible mentors (Team-XBMC will add this).

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". Of course 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

  • Summary: 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 user friendly nor future proof. I propose as a project 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 and 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!
  • What will the project focus on: XBMC, while amazing has quite a bit of feature creep and much of the functionality in XBMC is not as isolated as they could be. Since this project will take a lot of the technologies from XBMC it have the chance to create a set of libraries which are clean, reusable, isolated, designed outside of XBMC and used outside of XBMC. Some of the libraries which could be created as a part of this project is a VFS, scanning and scraping, URL and database libraries. When the project is done these libraries can be used in XBMC (or any other project) if wanted. The media server will act as a testbed for the libraries which are created whilst creating something of use for end-users of XBMC.
  • Benefits: From the users perspective they install the media server on his / her computer or server and the HTPC picks up the server and use it. If a friend pops by with a laptop with the server as soon as it enters the network the HTPC can use the content available on said laptop. Another scenario would be that the user have more than one XBMC installation, perhaps on his portable device or just many HTPC boxes. When adding a movie to the server all of these devices will pick it up and if one device watch the movie it is shared amongst them. The project will create a set of reusable libraries which allows which can be used by XBMC which could lead to a cleaner and more stable core, and a way to test functionality outside of XBMC.
  • Goals: Create reusable and clean libraries for VFS, database, scanning, scraping and media database.
  • What does it touch in XBMC: Nothing, it will require pulling technologies from XBMC
  • Requirements: C/C++ for the libraries to be created but Python for the server.
  • Possible mentors: