Design overview: Services

[Nikolaj Hald Nielsen]

Ok, I am going to keep this one fairly high level as trying to dive
into any amount of details in an email would cause it to grow to a
size where no one would ever read it.

The service framework provides 2 main things

1. the ServiceBrowser and ServicePluginManager. This is simply a
system for displaying and navigating between services in a consistent
manner.
2. The ServiceBase class and its gang of helper and utility classes.


The services are basically plugins based on the ServiceBase class.
This class itself does not do too much, except provide the functions
needed to integrate cleanly into the ServiceBrowser and a basic layout
that you can use or discard. Per default it also includes a
ColletionTreeView for displaying the actual content from the service.
Initially, all services used the collection framework to display
content, and most still do, but Casey recently modified the system so
it is also possible to bypass this completely and provide you own tree
view that populates itself however you see fit.Doing this means that
you have to provide all the functions for adding stuff to the
playlist, PUD integration and so on that are otherwise provided for
you but the CollectionTreeView.

then there are a ton of helper classes to make writing services easier.

There are stubs for Meta types and collections, and a rather advanced
system for services that wishes to use an SQL based collection, where
table creation and querying is handled automatically based on the
fields defined in the Meta types ( so you dont have to write your own
Collection and QueryMaker for each service ). For instance the
Jamendo, Magnatune and OPML directory services use the same Collection
and QueryMaker classes even though the database scheme for each are
quite different.

There is an InfoParseBase class that is used used as an interface for
letting each service provide a class that handles what information
should be displayed in the "service info" context applet based on the
current selection in the service.

The service info applet itself is fed by an engine that monitors the
ServiceInfoProxy class singleton instance that relays data from the
currently active service.

On top of all this is built the actual services that can, in essence,
include as much custom code as they need to do their job. the
Magnatune service, for instance, being the oldest and most mature
service, has a large number of classes used to handle purchasing,
memberships and a bunch of other features unique to this service.

Also as part of the service framework, but a bit of an odd fish none
the less (as it is as much part of the scripting system as the service
framework) is the scriptable service system. This allows simple
services to be created based on scripts.

So in essence you can say that the service framework is quite thin,
meaning that once you have a ServiceBase derived class, it is really
up to you how many of the utility classes  you want to use, or if you
want to go it alone.

- Nikolaj