Towards Amarok Mobile: Beginning separation

[Maximilian Kossick]

On Fri, Mar 19, 2010 at 10:49 PM, Jeff Mitchell <mitchell at kde.org> wrote:
> Hi guys,
>
> With commit 316911d22 I have taken my official first step towards Amarok
> Mobile  :-)
>
> This was discussed on IRC a while back, but for those not aware, the
> idea is to reuse as much code as possible...which basically means that
> two things are needed:
>
> 1) The ability to control which parts to build on a mobile system
> 2) Separation of GUI/logic
>
> I'll be pestering several of you individually in regards to #2. However,
> I want to lay out my thoughts on #1.
>
> My first goal is to get several of the services working. There are
> already music clients on Maemo; there aren't any Ampache clients or
> Last.fm clients. So I figure a good way to get established is to provide
> what's not already there, and then fill out the functionality as possible.
>
> To that end, some things that are definitely needed are Meta and the
> Memory collection. Having spent some time (and several false starts)
> looking at this problem, I've decided to try doing the following:
>
> 1) Move the bits outside of Meta that Meta depends on into Meta.
> * See commit 316911d22 for the first step in that regard.
>
> * My next idea is to move Collection/CollectionLocation into meta/. They
> don't have other dependencies, and this would leave collection/ as a
> place for actual collections and helpers, while keeping all of the meta
> information (including the collection metadata) in meta/.
>
> 2) Rejig the structure of meta/ and the CMakeLists; make building
> different parts optional.
> * If meta/ is reorganized it should be possible to built, or not build,
> different parts of meta based on CMake flags. This way on Maemo I could
> e.g. not build the File bits and thus not have a TagLib dependency at first.
>
> 3) Make Meta a library.
>
> 4) Repeat step 2 for collections and turn some of them into libraries
> (such as the memory collection).
>
> That's my current plan...if anyone sees gaping flaws or takes umbrage
> with any of the above, do let me know.
>
> --Jeff

Moving all those classes into meta/ does not make a lot of sense imo.
They are not providing track metadata after all. If you are planning
to do that refactoring, I suggest creating a "Core API" library
instead. Which could then continue to have the internal distinction
between meta/ and collection/. You did not mention QueryMaker, but
that would have to be moved as well.