GSoC considerations

[Edward Toroshchin]

Hi,

I guess the first question is quite important: who is going to mentor at
all?

On Tue, Apr 09, 2013 at 03:46:31PM +0200, Matěj Laitl wrote:
> I've added 3 ideas, but I might not be able to mentor them in case I'm 
> accepted as a student, however I plan to do code reviews. Please have a look 
> at these - if they seem nonsense, please shout early! "I could mentor this" or 
> "I suggest a change" are of course also accepted. ;)

They look quite good to me: well described and timely. For which one are
you going to apply yourself?

I belive I would be able to mentor either of the projects.

I didn't read into the details, though, I think we should do it together
with the students who want to apply. Those are ideas, after all, not
thorough project specs.

> I have also another idea on my mind: Scripting Interface Revival

Why revival? It's alive and kicking.

Still, this is a nice idea, but the project should start with a review
of existing scripts, API calls they use and don't use, probably contact
some of the script authors and ask what they like/dislike/want/don't
want (hey, script writers, are you reading this?).

> Myriam also suggests that we should run the "QML Context View" idea again and 
> I support it. Agreed?

No objection from me, but I don't think I'll be up to mentoring that.

I've also got an ambitious idea for the brave-hearted: a design of
Amarok 3 architecture. One should read carefully the Randa doc (scope,
vision, requirements), our codebase, and come up with the following:

 * the data model;
 * the big components layout (player engine, database, ui, ...);
 * the interaction between the components;

    My personal view on this point being: the engine, media database and UI
    (at least) must be separate processes, so that:

     + at least the first two can be made rock-solid, valgrinded,
       unit-tested, etc.,
     + the data structures and flows are strictly defined,
     + no bullshit a la "we can't use class XXX from YYY thread if ZZZ",
     + theoretically, any component should be completely replaceable.

    I'll try to describe the benefits (as I see them) of these changes
    below (if you bear with me).

 * which parts of the existing code can be spared and reused, and which
   would rather be killed with fire;
 * and so on.

I think it would be quite a challenging and interesting project.

Now, as promised, my view on the process-based architecture.

Although switching to IPC may seem over-complicated, I think it would be
actually much easier to live with than our current thread zoo.
Currently, before any tiny bit of code can be changed, a lot of things
have to be considered, which raises the entry difficulty for developers
a lot (and we're not in the best of situations there ATM).

So here are the benefits, as I see them (in a loose order of decreasing
importance):

 * it would be easier to debug and develop upon individual components
   (hence, improving the quality, userbase, and developer community),
 * database would be easy to replace (mysql, nepomuk, whatever), it
   might even become plausible once more to maintain several backends
   (although a sql and nepomuk would probably be the favorites),
 * the playback engine would do only playback, do it well, and not fuck
   up anything else (I believe currently the first question that's being
   asked in a bug report is 'have you tried changing the playback
   backend'),
 * UI might be replaceable. We might want to have a variant of an UI for
   low-performance systems. Web UI (someone mentioned recently)? Easy!
 * the environment and resource usage could be contained within each of
   the processes. Think MySQL (all the exit()'s, all the *argv, all the
   pain and misery and 500-megabyte caches for no reason).

Of course, this may not require splitting the components into processes
per se. But I still think the split is important, because it requires a
good fundamental design, and confines the development to it. Which is a
good thing.

Hope you don't regret reading all this! Cheers,

-- 
Edward "Hades" Toroshchin
dr_lepper on irc.freenode.org