Hi,

as you probably know, we are using a software called "enigma2" on the
dreambox. enigma2 is written in C++ and Python. The reason for not writing
everything in C++ is simple: C++ is very inefficient (in terms of sourcecode
manageability) when it comes to higher level tasks. We're trying to use the
flexibility of python to create a user interface which is easy to manage,
without becoming ineffecient or inflexible.

The reason for not using python for everything is probably even simpler -
performance. Plus some things are easier to write in C++. Then python
doesn't support threads (and that's good!). And finally, it feels better -
core parts are written in C++, user interface parts in python.

After all, the dreambox has a 300MHz MIPS CPU, and we certainly don't want a
slow reacting user interface. By the way the memory usage of enigma2
should not exceed 32MB.

Now, your task would be to write something for enigma2. We're more
interested in the python part of it. Now you probably don't have a dreambox,
and all that embedded development doesn't make things easier.

Now we have worked out a small "enigma simulation", called pynigma. It's a
small piece of python code, which tries to emulate enigma's interfaces.

In detail, a part of the "service subsystem" is emulated. A "service" is
comparable to a file / directory, just that it can be a "DVB channel" /
"program" (DVB uses the term "service" here), a real file, a directory, a
favourite listing etc.

A service does not have a fixed in-memory representation. Instead, it is
referenced by a "service reference", of which you can think of a string. In
real enigma, it's a bit more complicated, but thinking of it as a unique
string is ok.

With a service reference, you can also get the listing of a "service"
(for example to list the favourites), just like a directory.

Some services (like real dvb services) can't be listed, of course. Instead
they can be played, but that's not included in this simulation.

You can also query event data from it. 

There is a small example included.

As an example task, we thought of a network frontend. We don't really want
to restrict anything, but please keep in mind that making an SNMP interface
probably makes less sense (because there would be only like 10 people using
that) than something which is usable from any desktop computer's
preinstalled software.

Your target audience are end-users. They range from terribly stupid to
infinitely clever. If possible, care about all of them!

So you could do a web frontend, where channels can be listed, selected
and maybe epg information can be listed. It doesn't need to be
feature-complete, but should have some flexibility to allow adding these
features. In fact, we don't want to use that code, but it should show how
you would do such things.

Finally some notes:

 - you don't know python? GREAT opportunity to learn it. python is great.
 - please limit your work to +/- 200 lines of your own code. This is no
limit, it's merely meant symbolically. We do not expect a fully blown
application from you! It's about something "small". (so, don't count lines.
Just don't spend a year on this, that's all we want to avoid!)
 - python is NOT multithreaded. Hint: twisted.
 - writing a webserver is a cool homework, but there are already enough of
them. Don't re-invent the wheel! (hint: twisted.web, twisted.web2)
 - you're not a web designer? Don't panic. Use proper templating, so a web
designer could pick up the task. Keep in mind that web designers usually 
don't want to write code. (hint: twisted.nevow looks cool.)
 - You don't like a part of twisted, or twisted at all? Feel free to search
an alternative. However, the inability to read a tutorial is not an excuse
for writing/using a less cool replacement. 
 - Keep in mind that 1000 services are a lot of data.
 - The existing API suck? Use the available one, but you can leave a
comment why changing the API would be a good thing. For example, if you
can't get your stuff to perform because the API doesn't let you select the
right span of data, the API is probably worth improving.
 - The existing implementation suck? Yes, it does. You want to improve it?
fine, send us suggestions. However it won't have any influence on the
evaluation of the rest of your work.
 - Something isn't working, or you can't get it to work? Something is
just missing? Don't panic. Write a "TODO"-styled comment, and work around it.
For example, if you want to display the current volume, just emulate that,
and write a comment that "there was no volume api, so i had to emulate it."
 - Don't work around without a comment. 
 - Self-commenting code is better than unreadable code with a lot of
comments.
 - compact code is usually better than large code, unless it becomes
unreadable
 - python is cool. use it's coolness!
 - exceptions are a bit slow. keep that in mind when deciding whether to use
them or not.
 - Feel free to ask: Felix Domke <tmbinc@elitedvb.net>
 - If you want comments about non-finished code, no problem.
 - If possible, use tabs for indention.

Questions?

 - Felix