Re: [Jack-Devel] major change in jack1 MIDI handling

> 
> A few years ago, I would have had more to say (and did, at times,
> IIRC).  I'm not as familiar with the JACK 2 codebase as I used to be.
> 
> And you're right - it's not fair for me to express my dislike of the
> JACK 2 architecture, design, etc. and not give some specifics.
> 
> One problem I remember trying to wrap my head around was the Open
> functions in the JACK 2 driver system.  Let's take a brief look at
> those now.
> 
> 1.) The JackDriverInterface class has three pure virtual Open()
> functions.  IIRC, there isn't one driver I've seen that implements all
> three of these functions.  That's confusing.
> 
OK, I've just remove one of the Open method that was not really necessary (pushed on GIT)


> 2.) Then there's the JackDriver class that extends the
> JackDriverInterface class.  The class is meant to be a base class, but
> it implements all three of the virtual functions.  These
> implementations are meant to be called by subclasses that override the
> JackDriver virtual functions, which is an ugly anti-pattern.

Well the point is to have JackDriver implement *common* cases, and sub-classes possibly re-implement the Open methods, calling the *generic* case and then adding their specific stuff. 


>  If
> JackDriver's Open functions are called without the overriding wrapper
> function, then hilarity may ensue when the underlying JackDriver part
> of the class thinks the driver has been successfully opened.

Yes right, this is a pattern I had already seen elsewhere, what would you suggest as a better model?

> 
> 3.) There's also JackThreadDriver, which also extends the
> JackDriverInterface class (not JackDriver!).

Yes the JackThreadDriver class is meant as a decorator kind of pattern, so implementing the "interface", so JackDriverInterface class

>  It also provides
> implementations for the three Open functions, one of which just fails
> by returning -1.

Removed.


>  If the JackThreadDriver class doesn't need some of
> the API from the JackDriverInterface class, then either
> JackDriverInterface should be changed, or JackThreadDriver shouldn't
> extend JackDriverInterface.

The decorator pattern redirects call on the decorated object, and possibly implement specific stuff in some method.
> 
> 4.) Speaking of returning -1 for non-realtime errors, I'm of the
> opinion that throwing exceptions is a fantastic way to handle errors.
> It's okay to write data to stderr and to indicate that some sort of
> error happened, but it's even better to throw an exception containing
> a reason for the error occurring so that it can be handled at an
> appropriate place for handling errors.  Also, not checking return
> values for error codes again and again is a good thing.  Note that
> JACK 1 also has this problem; however, given that it's written in C,
> I'm a little more forgiving.

What would you suggest as a was to better use exceptions in the backend class hierarchy?
> 
> 5.) I said before that there isn't one driver I've seen that
> implements all three of the Open() functions.  Looking through the
> Linux-specific drivers, I see that JACKAlsaDriver and
> JackALSARawMidiDriver (I wrote that one) implement only one Open()
> function each.  Here's a bit of a curve ball - JackFreebobDriver and
> JackFFADODriver each define an Open function with a completely
> different signature!  So, why does JackDriverInterface have a public
> definition for Open() functions that may never be used, and aren't
> meant to be used at all at times?

The Open(….) is supposed to be used by subclasses to do the *generic* Open. Some subclasses (JACKAlsaDrivee, JackFFADODriver, JackFreebobDriver) have chosen a different prototype for their specific version, but sill use the generic Open one. I don't se that as a real problem

> 
> So, there's an example.  It's likely too little, too late, but
> hopefully you can generalize some of what I'm talking about to the
> rest of the code, because the problems above can be found in more
> places than just the Open() functions of Jack drivers.
> 
> Thanks,
> 
> -- 

Stéphane 

1381923661.11662_0.ltw:2, <5CF771B3-9AC1-45AB-993A-6E0C1E0E28F2 at grame dot fr>