Re: [Subhandler-devel] Some ideas for architecture

[Laurent P. <lau...@sk...>]

> The library may live as a shared object on its own used by a number of
> applications but it may also be stripped for direct integration on other
> applications (some like xine or transcode tend to favor this approach
> except for very general and well-established libraries).   So the
> library has to be constructed so that it is easy to select a subset of
> it.

Agreed.

> For subsetting, an architecture based on some kind of polymorphism seems
> easier that case switches.
> [...]
> Of course, this immediately suggests an object-oriented approach.

Agreed too.

> So, why not an OO language, such as C++?  Would all applications gladly
> use the dependency on a C++ compiler?  Not sure.  Besides, it is
> possible to get a lot of the benefits of an OO language simply by
> thinking in the right frame. For example, xine gets some benefit from it
> and with the help of a few macros it is possible to go a long way.  On
> the other hand it is easy to go overboard with this.  I think I have
> found the right balance, so I think I will progress with C.  But I am
> willing to reconsider at anytime.

Agreed again :-) I've been writing OO-oriented programs in C for years. I have 
to agree that using C++ is easier, as the compiler handles things that must 
be handled manually otherwise, but if we don't need all features of C++ 
(especially exceptions and multi-heritance), C will do the job.

> So, at the top we have a Subhandler_Object class, ancestor to all
> classes.  The general hierarchy would go like this:

What is a Subhandler_Object ? What kind of methods and/or properties will it 
hold ?

> Subhandler_Object
> 	Subhandler_Subtitle
> 		Subhandler_Subtitle_Bitmap
> 		Subhandler_Subtitle_Text
> 	Subhandler_Stream
> 		Subhandler_Stream_Submux  (subrip/submux)
> 		Subhandler_Stream_Philips_IMG
> 		Subhandler_Stream_DVD
> 		Subhandler_Stream_SVCD
> 		Subhandler_Stream_CVD
> 		Subhandler_Stream_SRT
> 		Subhandler_Stream_PPML
> 		Subhandler_Stream_SSA
> 		Subhandler_Stream_MicroDVD
> 		[etc.]
> 	Subhandler_IO
> 		Subhandler_IO_Text
> 		Subhandler_IO_MPEG_PS
> 		Subhandler_IO_MPEG_PES
> 		Subhandler_IO_VobSub
> 		Subhandler_IO_PS1
> 		Subhandler_IO_Program

Most OO-oriented frameworks written in plain C (Gtk+/Gnome comes to mind 
immediately) Don't use underscores in the name of the classes. Shouldn't we 
stick to the same rules (for letter of each work in uppercase for class 
names, without underscores, and lowercase with underscores for members and 
functions).

> Up to yesterday, I thought that IO was part of the Stream.  But then I
> found I was not getting enough reuse of code.  And I am separating
> tentatively both concepts to see if I can make sense of that structure.
> An IO can be seen also as a container.  This way it is possible to
> combine a stream with different IOs (I don't think it is a really good
> name, conduit might be better).  Not all combinations make sense,
> though.  For instance writing a SRT stream inside a VobSub would not
> produce an useful result.

I have some trouble figuring exactly what you put in which class, but I 
suppose it will be clear when I'll have a look at the code.

> Notice how we could select a subset of Stream and IO classes to provide
> a stripped-down version of the library.

OO rules :-)

> Feel free to comment on this.  As soon as I have a couple of classes
> semi operative, I will start commiting.  I am concentrating now on
> cloning the functionality of vobsub/submux (no multiplexing, though,
> just producing a PES).

I don't have more comments for now. I'm still reading docs about MPEG and 
subtitles. But don't worry, I'll jump in when you'll start commiting :-)

Laurent Pinchart