[haiku-commits] Re: haiku: hrev52055 - src/kits/media headers/os/media
- From: Dario Casalinuovo <b.vitruvio@xxxxxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Tue, 3 Jul 2018 15:37:35 +0200
Hi Stephan,
On Tue, Jul 3, 2018 at 11:42 AM Stephan Aßmus <superstippi@xxxxxx> wrote:
Hello Dario,
it is not the first time that you manage to stand out to me due to your
tone. Can you please maintain a nice or at least neutral tone and focus
on the subject matter?
I have not idea of what you are talking about. This is a commit mailing
list and did just comment like I could comment in any other development
discussion or web forum.
Am 03.07.2018 um 11:15 schrieb Dario Casalinuovo:
What's the reason for adding this half-done API?
The reason was given by the reference to the ticket. If you disagree
with this reason or have something to say about it, can you elaborate on
that instead of suggesting that no actual reason was given?
The subject of the concern is why making this API public in the first place.
And even in the end we have the same TODO "we should not!!! make flat
copies of media_format".
I guess because the commit is not concerned with fixing that TODO. Which
BTW is a very unhelpful TODO, since no reasoning is given.
The problem in question is that defining the meaning of "copying" and
"cleaning" of a media_format is very context sensitive. Doing flat copies
isn't very smart because of the way a media_format is built using unions,
and we don't know how BeOS precisely handled with that. One positive thing
is that those mechanisms are not used widely, or not used at all, so we
need to be careful about what we introduce.
We are trying to avoid adding new media_kit API, for the reasons stated
one hundred times, please make this commit to fix something or keep the
API clean.
If that is indeed the case, and it was stated so often, I really wonder
why I was not aware of it, given I still follow this list and the
developer list. In any case, I fail to see why these two added functions
could become problematic. If anything, they help to centralize a piece
of code so it can later be changed more easily.
We discussed various times how the media_kit already have a lot of unneeded
API that can be simplified.
Believe me or not, there's a lot of rust to clean out. It's an opinion, I
don't pretend you accept it as truth, but I have lots of reasons to say
that.
The position I have, that we have to stop doing API hacks and rethink
things the right way. As said you can accept it or not, but I think I made
pretty reasonable concerns in the past how *I think* the media API should
be carried forward, and do it properly without always reiterating the
errors from the past.
BTW Unflatten is confusing in any case, since it's not a BArchivable, we
do a good job confusing the programmer this way.
Yes. Do you have a better suggestion?
At the very minimum make this stuff private?
--
Saluti,
Dario
Other related posts:
