[vdr] Re: Proposal/Announcement: Alternative SI library

[Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de>]

Marcel Wiesweg wrote:
> 
> Hi,
> 
> when working with libdtv, I noticed some of its shortcomings:
> - the xMem-stuff is not thread-safe, VDR even has to use a global mutex
> - it is not possible to take a single part of a parsed structure, e.g. a
> single descriptor, and store it for later use (this also comes down to xMem)
> - it makes heavy use of macros
> - it's plain C, VDR is object-oriented
> - there is even code which g++ refuses to eat (xForEach)
> - everything is parsed, even if you only want to read a part
> 
> I want to announce an alternative library, libsi, available from
> http://www.wiesweg-online.de/linux/vdr/libsi-0.1.tar.gz
> 
> Advantages:
> - Object-oriented approach, C++
> - thread-safe in the sense that you can use the library from different threads
>   with as much objects as you like. Thread-safe access to a single object may
> require some work on the underlying storage class
> ...

This came just in time for VDR 1.3 :-)

The diff you provided doesn't remove the libdtv stuff from the makefile.
Does this mean you still use parts of that lib? A short glance over your
code would indicate you don't...

Also (again, this is just after a quick glance at the code, so please forgive
me if I've overlooked something): the section data that VDR 1.3 will distribute
to the individual filters (maybe implemented by plugins) will be 'const u_char *'.
For instance, the new cFilter class will have a member

 virtual void Process(const u_char *Data, int Length);

which will be offered any section data block that gets received (and
was requested by that filter), but must not alter that data in any way.

I'm wondering whether your functions all accept 'const' data.
If they don't, you may want to change that.

Klaus


-- 
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe vdr" as subject.