New directions for DVD Metabase: development odds and ends…

In this article:

* A new DVDMB C++ API

* To plug-in or not?

* To Mono or not?

* To Java or not?

Greetings all, JeffC here. While I am here in Las Vegas looking for work I have started to take EZRip/DVD Metabase into a few new directions. First, while there will *always* be a Python version of EZRip (and probably DVD Metabase), I have never made a secret of the fact that I have used the Python as a way of quick prototyping new project ideas.  Now after 5 years of development I have observed that for the most part the feature-set of the system has settled down. Also, while I see it as a useful rip tool in and of itself, I can also see uses as a component of a larger/different system, both on the rip side and the playback side, not to mention that holy grail of Netflix-like services, suggestions.

A C++ API…

One way to make this useful in other places is to wrap the core functionality in a plug-in-esque environment. As it is EZRip uses the following key services:

* Volname (collects the disc label, comes with Linux)

* XML-RPC (Web services architecture for performing transactions with the DVD Metabase server: Python)

* DVD scanning (collecting disc track, language and subtitle information, provided by lsdvd)

* DVD Disc hashing (calculating an MD5 hash of the disc contents for disc lookups, provided by disc_id from the libdvdread source)

To this end, I have started rewriting all of EZRip as a C++ project. With the exception of the rip engine itself (Handbrake in this case but more on that in a moment) all services will either use stock Linux libraries (libdvdread, libxmlrpc) or other open source libraries (SimpleINI). I am creating an interesting API that should allow other programmers to use these services however they wish.

So far I have readers/writers for the configuration file (which is now an INI-style affair), profile and filter files. On the XML-RPC side I have readers for doing a DVD lookup (supply a hash ID and get a main record plus a deque of 1-n track objects). On the DVD scanning side, I am still wrapping volname calls but intend to use libdvdread for that, a simple call that returns an MD5 hash based on a device path and am in the middle of sorting out the direct calls needed by libdvdread to perform the scanning job. So far I have that last bit collecting track, time duration and available audio track information; after fixing a few bugs and gathering the subtitle information, you should be able to pass in a device path and get back all of the information you need to do track processing.

All of this will be exposed via a well-documented API, allowing other developers to do disc lookups, retrieve DVD metadata, read and use filters and profiles and more, all by simply including a single shared library and a header file; no more screen scraping (woowoo)! As a proof of completeness of this, I will  be rewriting EZRip to use this API and make for a faster/more extensible rip tool. As a part of this I will be implementing the concept of a modular rip engine system so that you can easily apply the metadata lookup abilities to not only HandBrake but OGMRip and Mencoder as well. Currently the make system for it will be the ever-trusty cross-platform maker, CMake. I have a lot of years of experience with this and feel it to be a safe choice for this project.

The first version of this will be pretty much a work-alike of the existing system (with the exception of a different format for the configuration files, natch) but then things are going to get interesting. First, for the sake of my long-suffering wife I am going to create a GTK GUI-based version of this tool. While it won’t be anything terribly fancy, it should remove most of the rough-edges that the command line tool presented (like the interrogation in interactive mode).

The next step however may cause some consternation and indeed it has in my own mind as well. One of the larger debates (flame-wars) happening in the open-source community right now is over the use of Mono which is an open-source impelentation of the .NET framework and tools invented by…..Microsoft. One thing I have never made a secret of is the fact that I do in my professional work a lot of cross-platform development and so whenever I approach any non-trivial project, I do with with an eye towards that end. On the system side the only remaining non-neutral component is libdvdread and that will by then be sufficiently abstracted. Handbrake is already cross-platform. That pretty much leaves the presentation side of things which is one of the places where solid cross-platform development strategies totally live or totally die. Which brings us back to Mono.

To Mono or not to Mono?

As someone who has lived through Microsoft’s early and shamelessly anti-competitive years, I cannot say I would ever trust them.  I can see any number of ways they can screw over the open source community with .NET/Mono and not for a second do I think they would hesitate if given the chance. However I also have to say I am a pragmatist to an extent and since I started doing Windows coding back in the early 90’s and had to wrestle with the SDK of the time, I really appreciated the power and architecture of Delphi (and later Borland Builder). It just seems like GUI and component-based development done right. And guess who is behind the design of .NET at Microsoft? You guessed it: Anders Hejlsberg, creator of Delphi. This suddenly puts things in a whole new light. Frankly if all it presented was another way of doing cross-platform development, I would say the risk of working with Microsoft technologies was not worth the gain since there are several other (safer) ways of doing the same thing (wxWidgets, GTK, Java/SWING, etc). However if you have ever had to develop with Delphi/Borland Builder you would know this is absolutely NOT just another cross-platform solution.

It is with this mindset that I am even remotely consideging using Mono for the next evolution of this tool.  Yes I KNOW the Mono side will always be years behind the .NET side (regardless of what Miguel De Icaza would have you believe but then no developer with his or her salt believes anything he says anymore. Once he was a great developer but now he is a salesman, pure and simple. I don’t trust car salesmen either) and will never be feature-comparable. That said I am going to take a serious, non-biased look at the platform and if it seems safe enough and feature complete so I know it won’t be a total waste of my time, I will probably make a Mono version of the toolset and a GUI front-end for it. This however brings me to one last point on this….

To plugin or not?

While I do have a few patents to my name, I still don’t like what it does to otherwise sane people. Lately the company Eolas has brought suit against the world + dog (as seen here ) for creating things with plugins or using a plug-in like architecture…people, *please*! This model of application design is not only the most flexible and sane way of applicaition development, it is OBVIOUS! This application (EZRip) will be no different but if Eolas gain any traction with their ridiculous claims, this may have to be revisited.

Another direction I might take this (mostly to scratch an intellectual itch) is to write a Java-based version of this. I see it as a way of taking a design I know well and using a variety of technologies to bring it to life. I figure in this way I can honestly determine if one technology or the other is worth spending my time on. You as a C++, .NET/Mono or Java fan what is the best tool for the job and their answer is predictable. This will be my way of walking a mile in someone else’s shoes…

Status:

Currently I have proof of concept code working with configuration, profile and filter files.

I have volname wrapped (popen) but intend to use libdvdread to get the volume label directly.

I have the DVD hashing code done as a library.

I have most of the DVD scanning code done but this needs lots of testing.

I have XML-RPC code done to interact with the back-end server @ jbcobb.net:8000. I still need to flesh out the code to do a disc submission and update existing records to complete this section.

Unless something comes up, I am expecting to have the C++ command-line version of this done within two weeks. I will publish all code at that time and under the GPL.

Until later then, me to you…

JeffC