[harshitgarg]

Hello

I am a college freshman, majoring in CompSci. I am interested in working with Kodi on the project "Better profile support".

I first started using Kodi around 2-3 years ago, to set it up on my Raspberry Pi (Model 3B+) as a media center (of sorts), and so am quite familiar with the User Interface.

I have some experience with C++ (from my high school days), and am willing to learn new things as the need be. I am also familiar with git (and github), which I see Kodi uses as their VCS.

I was looking for help for the following :-
1. It'd be helpful if someone could give me pointers as to where I can start learning about the existing profile support in Kodi, and get familiar with the development process.
2. What exactly are the aspects in which we intend to improve profile support, if there are any pre-decided?

Have a good day
HG
:-)

[Razze]

Hey there nice to have you here.

1. So in reality we want to remove profile support and redo it from the ground up.
2. Problem right now is that we don't have a central easy to adapt well thought out implementation.

[harshitgarg]

So, I was looking for some more clarifications, to better understand the problem (and create a possible road-map on things to possibly work on over the summer) :-

1. Going around the forums and github issues, I understand that the current implementation is a mess, and since we can only patch so much, the team has thought it better to start things fresh with Profiles. In what ways exactly is the current implementation causing problems? It'd be helpful to know what all problems the current model presents to provide a better solution.
2. Are there new features planned to be added over the summer? If so, I do have a few ideas which I think can be implemented (Installation of addons per profile being one)


CC: @spiff , as he is the mentor of the project.

[spiff]

I am tremendously busy today but will answer properly tmrw. Hang in there

[spiff]

the main problem of current implementation is that it's was hacked in on top of already existing non-profile aware code. this leads to a lot of issues with initialization order etc, since application state is mixed up in profile state. e.g. logging in/out has to restart a lot of application services, and is very order sensitive. we mostly have this one under control, but the current solutions are fragile. a clean approach where the application obtains these services from some profile instance, including the ability to not have them, would go a long way to alleviate these problems.

a clear mapping of the dependencies and such would be needed, and then moving a lot of services from application to a profile class, and updating the user code to grab from there (and gracefully handle no instance conditions).

new features is not really part of the task, it is more about making it possible to extend it later. of course, if there is time, new features would be welcome.