Hi VN, Serg, all !
Narayanan wrote:
> Joerg Thanks again for this reply. I really appreciate you reply inspite
> of the cluster work you had.
>
> Joerg Bruehe wrote:
>> Hi !
>>
>> Sergei Golubchik wrote:
>>> Hi!
>>>
>>> On Aug 26, Joerg Bruehe wrote:
>>>> Sergei Golubchik wrote:
>>>>> On Aug 26, Joerg Bruehe wrote:
>>>
>>>>> [[...]]
>>>> I haven't worked in that area, so maybe my question is silly: As we
>>>> want to support storage engines as plugins, doesn't that mean their
>>>> sources have to include both "mysql_priv.h" and "plugin.h" ?
>>>
>>> Correct, it does. But these correspond to different API's. Moving
>>> something (e.g. a function prototype) from mysql_priv.h to plugin.h,
>>> means that this function was *added* to plugin API. This fact alone
>>> means that plugin API version should be increased. And it's unrelated to
>>> what has happened to mysql_priv.h.
>>
>> That's a good example.
>> A storage handler needs to include both "mysql_priv.h" and "plugin.h",
>> so if a function is moved from the first to the second header this
>> does not break existing source code (not even binaries).
>
> *This move does not show a normal situation at all*.
>
> *This is not like a c file where you move a function from one included
> header to another*
>
> In a JDBC driver you have Connection and Statement. So you do a
>
> import java.sql.Connection
> import java.sql.Statement
>
> what you are saying is equvivalent to saying I will move a function from
> Connection to Statement and then call it a valid move.
No, don't put that into my proposal.
My remarks below apply here as well: There might (should !) be an
interest to minimize application changes, if possible, and so such API
changes might (should !) not be judged independent of each other.
>
> [[...]]
>
>> [[...]]
>>
>> I never said this would leave the API/ABI unchanged, the move could be
>> done freely, or such, all I want is to provide the overall view.
>
> This move cannot be done freely. You cannot move functions between two
> semantically different API's.
I know that. I never meant to claim this were possible.
My idea was that *if* such an operation happens (an unlikely event), or
if several APIs (header files) get changed in sync, or ...,
then it would be better to have the general view.
I still see advantages in that, even if you explain the operation as
such would be invalid (which I accept).
>>>
>>> [[...]]
>>>
>>> There will be .pp and .out files, which can be compared by the tool of
>>> choice. The fact that make fails on the first mismatch means that
>>> developer will need to work on changes filewise, or, rather, API-wise.
>>> Because "API" is a reasonably independent unit, it's ok to work on
>>> changes API-wise, not all at once.
>>
>> Sure it is ok to do so, if the developer chooses.
>>
>> But I do not want this choice to be enforced - the developer should
>> not be prevented from using the overall view, IMO.
>
> If the developer is doing things correctly he would not need this
> overall view. I am still humbly saying that this move is not valid
> at all. He does not need this overall view at any point of his work.
As you both insist there would not be an advantage for the developers,
so be it.
It isn't me (in the build team) who would need that general view, so for
me this is the moment to stop objecting.
==============
Summary:
If I had it my way, I would try to handle some aspects different.
I have made my reasoning obvious in the mails, I hope.
But I don't claim the approach wouldn't work, or wouldn't serve its
purpose, or would negatively affect my work.
It is obvious that Serg (as an experienced developer) agrees with the
approach and doesn't see any significant shortcomings,
so I will stop objecting.
Go ahead and push it !
Regards,
Jörg
--
Joerg Bruehe, MySQL Build Team, joerg@stripped (+49 30) 417 01 487
Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering Muenchen: HRB161028
