Outdated MediaDeviceFramework

[Matěj Laitl]

On 25. 4. 2013 Tatjana Gornak wrote:
> While working on my gsoc proposal I did some research on Collections
> and I am not sure that I understand why MediaDeviceFramework is
> outdated (it states in few places, but without mentioning any
> particular reason). Maybe there is some additional info somewhere and
> I just did not find it?  I've looked at following documents:
> OUTDATED-MediaDeviceFramework,  architecture/Collections.txt, plus
> gained some info from comments.

The real reason is that the MediaDeviceFramework is so complex that nobody 
(apart from the original author) is able to satisfactorily maintain it. The 
single main problem is the design. We have nice abstract classes for 
Collection, CollectionLocation, Track, Album in core Amarok ... with rather 
nicely separated responsibilities. With MediaDeviceFramework, you don't 
however implement the nice ABCs.. you implement a Handler, which literally 
does everything the mentioned classes do. This leads not just to ugly code, 
but unnecessary (memory) overhead, memory management nightmares etc. etc. Not 
to mention there is a *separate* MediaDeviceCapabilities framework, 
independent from our "normal" Capabilities framework.

> Second question (I think it is question to Matěj, since he has
> formulated gsoc ideas). Is there reason why you do not formulate more
> general task for gsoc: rewrite not only audiocd collection, but also
> mtp?

Very good question, the answer is simple: MtpCollection rewrite will be my 
GSoC proposal. :-) I will send my proposal for review to this ML later today, 
it may contain more background information that you might find useful.

More technical reason is that MTP + AudioCD rewrite would be too big for 
summer for newcomers. I consider MTP rewrite a "normal" medium-sized project 
very appropriate for GSoC. AudioCD may be a little bit smaller than MTP, but 
see below.

> And last one, is there some specific requirements for collection of
> new type (if so, I think I should mentioned them in proposal)?

What does "collection of new type" mean? General requirements for new 
collection is that it would implement all meaningful abstract interfaces 
offered by the Amarok "framework" in a best possible way.

Because AudioCD rewrite might be a medium or a bit less-sized project, 
additional goals may be set up:
 * very high code quality (only best coding practices, exemplary use of 
consistent coding style...)
 * very high level of user-visible polish (error reporting, solidness...)

It may well happen (but may not) that you achieve the goals before the coding 
period ends. Don't fear, there's always more work to do. :-) In arbitrary 
order:
 * making AudioCD work on Windows (involves cooperation with kde-windows 
people)
 * support for AudioCD burning? (perhaps k3b can be somehow integrated?)
 * making copying out of the CD work without kio-audiocd (may not be worth it)
 * working on removal & cleanups after removal of the MediaDeviceFramewrok 
(depends on my GSoC)
 * documenting undocumented core classes that you implement along the way
 * cleaning up/improving core classes/API that you find suboptimal along the 
way...

^^^ I think you may mention any or all of the points (and perhaps your own) in 
your proposal, as you see fit.

Cheers,
		Matěj