Thank you for the comments and guidance through this issue Joerg and Serg.
I shall request for a push ticket for this form the team tree captains.
Thanks once again,
Narayanan
Joerg Bruehe wrote:
> 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
>
