Hello, please find my comments inlined.
On Sat, Feb 6, 2010 at 18:49, Rocky Bernstein <[email protected]> wrote: > On Sat, Feb 6, 2010 at 12:15 PM, Mario Đanić <[email protected]> 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
