libcdio-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Libcdio-devel] Re: mmc_get_disc_erasable proposition + questions


From: Mario Đanić
Subject: Re: [Libcdio-devel] Re: mmc_get_disc_erasable proposition + questions
Date: Sat, 6 Feb 2010 19:24:46 +0100

Hello,

please find my comments inlined.

On Sat, Feb 6, 2010 at 18:49, Rocky Bernstein <address@hidden> wrote:
> On Sat, Feb 6, 2010 at 12:15 PM, Mario Đanić <address@hidden> wrote:
>
>> > And at the same time, where folks want strict compliance for any given
>> > standard they can get that too by using the specific library desired.
>> >
>>
>> Sigh, that sounds like a bunch of libraries.
>
>
> I don't see that the *number* part is a problem. Right now on my ubuntu
> computer in /usr/lib  I have 351 shared libraries (.so's).  And if I do a
> "ldd xine" I come up with 41. If the numbers were 355 or 45 that wouldn't
> bother me at all.
>

As a random user, I don't bother about number of libraries either. But
when I have to develop things, I need to choose what to use - more
choices often lead to more confusion.
Education and documentation helps, but this problem is not trivial,
and we can't dismiss it off-hand as non-important.

> Applications only need to use those libraries that are desired. The author
> of the application is in a better position that me or libcdio to know how
> much generality and compliance is desired.

I agree, the author of the application is in the best position to do that.

>
> It sounds like you wants to create a single all-encompasing library that has
> might have loose compliance with anything but is very practical and can do
> everything folks are likely to want to do in optical media, then that's the
> one library your burning application might access.

I want us to make burning a pleasant experience. So far a lot of the
people I've had the privilege to talk to had numerous problems. Some
are related to GUIs, some to underlaying technology, etc, etc ... but
the thing is - we don't yet provide a consistent and nice experience
for the average, or not so average Joe.
>
> On the other hand, suppose you are doing something strictly of a CD nature
> and say only care about Red-Book CDs. Then although one could use the
> everything hybrid library, I think I would tend to use the libcdio library.
> If nothing else it would be stricter about ensuring that you come up with a
> valid CD because that's all it *could* do.
>

How about designing the api so it would have a "strict" mode? Please,
do not think that I am against several libraries. If there is a valid
reason for creating a new library from scratch, or by stripping-out
parts of code from anything existing (like libburn or libcdio) I am
all for it.

>
> From my position, optical
>> media recording scene is fragmented enough as-is, and one of the
>> reasons behind Libburnia project is to unify efforts on "burning"
>> matters on Linux, and then possibly other platforms.
>>
>
> So again, I think what you want is this hybrid loose compliance library for
> burning. And the best way to make sure it happens is to "vote with your
> feet" or do it.

I can only hope I've helped that cause at least a bit with the
libburnia project.

>
> So I'm just suggesting doing this separate from libcdio *library* which was
> intended for CDs.  (It is open for discussion as to whether you want to do
> this inside the libcdio *project* or outside. If there are internal parts of
> libcdio that should be moved outside to help things along, that's okay.
> We've discussed for example moving MMC outside by turning it into a library
> which libcdio and perhaps libburnia use)
>

I have no problem with moving MMC parts outside both libburnia
libraries and libcdio. In fact, I might have something to offer on
that ground as a starting point for discussion.

> Personally I think doing this makes things much cleaner and easier to work
> on. There is no backward compatibility to worry about. Furthermore one can
> reassess any of the assumptions made in a more fundamental and radical way.

Cleaner, and easier to work with? ++ on that one.

>> I will try to get up to speed as soon as my laptop is back, and in the
>> mean time I'll read your discussions as I can.
>>
>
> I look forward to your thoughts and views. Thanks in advance for any help
> you can give.
>
> Quite frankly I do not consider myself an expert any of the things libcdio
> purports to understand. As I wrote in the history section of libcdio
> documentation, this started as my own personal and individual discomfort
> with DMCA.
>
I will try to help as much as I can. While I'm most certainly not an
expert, I've picked up a thing or two, and have a lot of experience
about how users perceive optical media recording gathered from the
conferences where I spoke about burning and from maintaining
Gnomebaker.

Cheers,
Mario




reply via email to

[Prev in Thread] Current Thread [Next in Thread]