Re: Cd Burning

[John McCutchan <ttb tentacle dhs org>]

On Mon, Sep 16, 2002 at 10:28:09AM -0400, Sean Middleditch wrote:
> On Mon, 2002-09-16 at 10:08, Bastien Nocera wrote:
> > On Mon, 2002-09-16 at 14:31, Sean Middleditch wrote:
> > > 
> > > Well, for one, CD burning would be better off in a separate process than
> > > the main app, just for the sake of retaining interactivity without the
> > > chance of buffer-underrun.  And, while threads can manage that, a bonobo
> > > interface would be more capable of queuing burning requests, no? 
> > > Something like if I tell Rythmbox to burn a Rock CD and an Anime
> > > Soundtrack CD, it would make both requests, those would get queued by an
> > > interface activated thru bonobo, which would burn, handle notification,
> > > etc. etc.
> > 
> > Riight. You can write a bonobo component with a library, you can't
> > (decently) write a library from a bonobo component. After you've written
> > the library, how much glue you fancy is up to you.
> 
> This depends.  Writing a library designed for a simple burning interface
> in an application isn't going to get one very far given the above goals,
> at all.  If you just want a library, use libcdrecord.  Designing the
> code form the ground up to serve/queue multiple requests, in an
> out-of-process fashion from the application, saves time, versus writing
> it once as a library than again as a service, especially given how 90%
> of the code is going to be the glue itself - why write a library to
> handle CD burning, then a service to interface to this library, which
> increases code size and dependencies, versus just writing the service
> and be done with it?
> 

Because it doesn't make sense from a design point of view to have
the service interface handle all the architecture and system
dependencies. Creating a simple library that abstracts the hardware
and then creating a bonobo service on top of it makes sense. The
bonobo component should not be handling the low level hardware.

john