10
10
Modern media player applications enable users to consume content
11
from various service providers, both local and on-line: Youtube,
12
Jamendo, Flickr, SHOUTCast, UPnP are a few examples of this trend.
17
Creating powerful applications that are capable of integrating all
18
these services is a time consuming task that requires to invest
19
a lot of effort not only in coding but also in learning about all
20
these services and the particularities of each one.
25
Unfortunately, applications that already implement support for
26
some of these services do so in a way that is application-specific,
27
disabling the possibility to reuse this code directly in other
28
projects. This means that other applications out there have to do all
29
that work again if they want to integrate the same services.
11
from various service providers, both local and remote: Youtube,
12
Jamendo, Flickr, SHOUTCast or UPnP are a few examples of this trend.
17
Creating powerful, modern media applications that integrate content
18
from multiple services is a time consuming task that demands
19
a lot of effort on various fronts:
21
<listitem>Learning all the APIs involved.</listitem>
22
<listitem>Learning and integrating all the required technologies.</listitem>
23
<listitem>Abstracting the differences among content providers.</listitem>
24
<listitem>Maintenance.</listitem>
29
Unfortunately, applications that implement support for
30
these services nowadays do so in a way that is too application-specific.
31
This disables the possibility of reusing the solution in other
32
projects directly, meaning that other solutions have to do all
33
that work again if they want to accomplish the same target, which is
34
rather inefficient and makes this type of solutions quite expensive
35
in terms of development time and maintenance.
33
39
In this context, the target of Grilo is to provide application
34
40
developers with a framework where they can work together in the
35
creation of application-independent plugins for managing media content
36
that can be reused directly by applications. This model adds a number
37
of important benefits:
41
development of application-independent plugins for managing media content
42
that can be reused directly in modern media applications. This model comes
43
with a number of important benefits:
40
49
<para><emphasis>Less work on the application side.</emphasis>
41
All the plugin development happens in the framework and application
42
developers can focus on making good user interfaces. It is the
43
same with GStreamer if you think about it, application developers
44
do not have to write decoders to playback content any more, they
45
get the decoders from GStreamer (the framework) and that eases a
46
lot application development. Well, this is the same idea, but applied
47
to media browsing and discovery instead of media playback.
50
Plugin development happens in the framework and application
51
developers can focus on making good user interfaces instead.
51
57
<emphasis>Code reuse.</emphasis>
52
There are many media player applications allowing users
53
to access contents from various services. This is nice, but all this
54
is done at the application level, which usually means that all that
55
code cannot be directly reused in other projects. Because of that
56
there are developers writing application specific plugins for all
57
these services in various applications (Totem, Rhythmbox, Amarok,
58
etc), replicating code that cannot be reused directly in other
59
applications. If the plugins were developed on the framework side, all
58
There are many applications allowing users to access media content
59
from various providers though application-specific plugins.
60
If the plugins were developed on the framework side, all
60
61
these developers could share efforts and write support for these
61
62
services only once in the framework, making them available for all
62
63
the applications using the framework for free. Every one wins.
66
69
<emphasis>Quick learning curve.</emphasis>
67
70
If you want to write a media player with support for various
68
media content providers, you would have to learn how to deal with
69
each one of them independently: want to add Youtube videos? go and
70
learn about Youtube data API, want to add music from Jamendo? go and
71
learn about how Jamendo allows you to do that, want to provide access
72
to your local media? Go and learn how Tracker APIs work for example,
73
want to access UPnP servers? then go and learn about using GUPnP,
74
and so forth. This is a lot to learn, and even more code to implement.
75
The framework approach would ease all this, one would have to learn
76
only one API (the framework API) and that would enable application
77
developers to access all these services through the framework plugins.
71
content providers, you have to learn about each one of them independently:
72
Want to add Youtube videos? then you need to learn about the Youtube data API.
73
Want to add music from Jamendo? then you need to learn the ins and outs of the
74
Jamendo API Want access to local media? Then you might want to learn about Tracker
75
and its APIs. Want to access UPnP media servers? Then it is time for you to learn
76
about the UPnP protocol and the GUPnP library, etc. This is a lot to learn,
77
and even more code to implement and maintain. The framework approach would make
78
all this a lot more straight forward for application developers, they would need
79
to learn only one API (the framework API) and that would enable them
80
to access all these services through the framework plugins.
81
87
Application developers will find in Grilo a framework they can use
added
removed
doc/grilo/overview.xml
