[GEM-dev] [pix_record] api question

[IOhannes m zmoelnig]

hi.

chris clepper wrote:
> The problem with this situation is that you broke working code and
> made no accommodations to anyone else who might rely on that code. 

of course it was not my intention to keep anyone from working because 
some objects are broken.
however, due to the nature of CVS there is one accomodation:
~> cvs -z3 update  -D "2006-02-01 00:00:00"

> You could have implemented the new API without touching pix_record at
> all by making a temporary file like pix_recordNEW or whatever.  This

right, and have the same chaos as we still have with pix_film. i am 
trying to avoid exactly that.
have 2 (or 3) objects which provide approximately the same functionality 
(but unfortunately not exactly the same)

> would have allowed for a gradual transition of the code without

yes it would have allowed for that. but nobody would have cared on the 
long term, because "it worked (on my box)"

> breaking anything.  The timing is really bad too because I really need
> the current CVS pix_record to work on OSX right now.  I may or may not

that is why i would like to make right in the first place (what is 
"right" is of course subject to discussion)
again, i am sorry if a broke your current working environment.
however, the timing would have always been bad.

> have a problem with the object's long term stability and the changes
> you made are not helping right now.

> I will work on the common API version when I get the chance, but I
> have other things that come first.  Also, the current version has been
> tested for many months, and I would like to do the same with the new
> version as well.

which is definitely a good point in your argument.

> 
> So can we put a transitional file in place for a little while until I
> get things sorted here?  If you don't want to do a pix_recordNEW then
> I will commit a pix_filmQT or similar for the time being.

i would prefer if somebody (who has a working environment on os-x) 
looked into the code of the common API and fixes it.
if this is not feasible (because of more urgent matters) i would prefer 
to name it "pix_recordQT", instead of naming the common api-object 
"pix_recordNEW"; and put a HUGE "#warning" pragma into the source-file 
so people get reminded that something needs to be done.


i guess we can all work this out.

mfg.a.s
IOhannes