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
_______________________________________________
Amarok-devel mailing list
Amarok-devel@kde.org
https://mail.kde.org/mailman/listinfo/amarok-devel
