List:Internals« Previous MessageNext Message »
From:Brian Aker Date:April 3 2009 2:21pm
Subject:Re: [patch] plugin build process improvements
View as plain text  
Hi!

I got pinged about this and was asked to share my thoughts.

In Drizzle we have moved toward picking classes which we are  
identifying as API. This is a slow process and has required us to  
rethink some classes in order to provide what we feel will be a good  
long term API (and we are not finished with it either). The class  
structure in MySQL is more of a "public structure with functions" then  
any sort of real API. I would think twice before just opening up all  
of these to the world.

Opening up the class headers means you are creating a pact between you  
and your developer base. You are saying "this is an API, we promise to  
inform you of changes, and to not make them lightly". Is this where  
the MySQL codebase is today?

Cheers,
	-Brian

On Apr 3, 2009, at 7:10 AM, Antony Dovgal wrote:

> On 03.04.2009 17:44, Davi Arnaut wrote:
>> There needs to be a separation between private (to the server) and
>> public (exposed to the plugins) structures, we can't just expose  
>> all of
>> then without creating a mess as it might later hinder our ability to
>> modify or fix internal structures without causing havoc for the  
>> plugins.
>
> I understand you concerns.
> If you are fully confident that some header file must not and can  
> not be used by
> any plugins - fine, don't install it. Can you define such files?
>
> As far as I understand (correct me if I'm wrong) both private and  
> public structs
> are defined in the same headers, so separating them would require  
> much bigger
> patch than the proposed one.
>
>> We should be looking at this on a case-by-case basis. Or we decide to
>> not guarantee stability on the exposed structures. What do you  
>> prefer?
>
> I truly believe that any plugins doing weird things with structures  
> they shouldn't
> be using at all do deserve to be broken.
>
> What did you mean by case-by-case basis?
> I can try to figure out which headers are required to build my  
> plugin, but others may
> need something I don't use, which means the problem would be still  
> there, just hidden for some time.
>
> -- 
> Wbr,
> Antony Dovgal
>
> -- 
> MySQL Internals Mailing List
> For list archives: http://lists.mysql.com/internals
> To unsubscribe:    http://lists.mysql.com/internals?unsub=1
>

--
_______________________________________________________
Brian "Krow" Aker, brian at tangent.org
Seattle, Washington
http://krow.net/                     <-- Me
http://tangent.org/                <-- Software
_______________________________________________________
You can't grep a dead tree.



Thread
[patch] plugin build process improvementsAntony Dovgal18 Mar
  • Re: [patch] plugin build process improvementsChad MILLER18 Mar
    • Re: [patch] plugin build process improvementsAntony Dovgal18 Mar
      • Re: [patch] plugin build process improvementsSergei Golubchik18 Mar
    • Re: [patch] plugin build process improvementsAntony Dovgal19 Mar
    • Re: [patch] plugin build process improvementsLenz Grimmer24 Mar
  • Re: [patch] plugin build process improvementsSergei Golubchik19 Mar
    • Re: [patch] plugin build process improvementsAntony Dovgal19 Mar
      • Re: [patch] plugin build process improvementsSergei Golubchik19 Mar
        • Re: [patch] plugin build process improvementsAntony Dovgal20 Mar
          • Re: [patch] plugin build process improvementsMichael Widenius22 Mar
  • Re: [patch] plugin build process improvementsHartmut Holzgraefe19 Mar
    • Re: [patch] plugin build process improvementsMichael Widenius22 Mar
      • Re: [patch] plugin build process improvementsHartmut Holzgraefe23 Mar
        • Re: [patch] plugin build process improvementsMichael Widenius17 Apr
  • Re: [patch] plugin build process improvementsChad MILLER19 Mar
    • Re: [patch] plugin build process improvementsAntony Dovgal20 Mar
    • Re: [patch] plugin build process improvementsAntony Dovgal3 Apr
      • Re: [patch] plugin build process improvementsChad MILLER3 Apr
        • Re: [patch] plugin build process improvementsAntony Dovgal3 Apr
          • Re: [patch] plugin build process improvementsDavi Arnaut3 Apr
            • Re: [patch] plugin build process improvementsAntony Dovgal3 Apr
              • Re: [patch] plugin build process improvementsBrian Aker3 Apr
                • Re: [patch] plugin build process improvementsAntony Dovgal3 Apr
                  • Re: [patch] plugin build process improvementsKonstantin Osipov3 Apr
                    • Re: [patch] plugin build process improvementsAntony Dovgal4 Apr
                      • Re: [patch] plugin build process improvementsSergei Golubchik4 Apr
                        • Re: [patch] plugin build process improvementsAntony Dovgal4 Apr
                          • Re: [patch] plugin build process improvementsSergei Golubchik14 Apr
                            • Re: [patch] plugin build process improvementsAntony Dovgal14 Apr
                            • Re: [patch] plugin build process improvementsAntony Dovgal7 May
                              • Re: [patch] plugin build process improvementsSergei Golubchik7 May
                                • Re: [patch] plugin build process improvementsAntony Dovgal7 May
              • Re: [patch] plugin build process improvementsDavi Arnaut3 Apr
                • Re: [patch] plugin build process improvementsMats Kindahl3 Apr
          • Re: [patch] plugin build process improvementsChad MILLER3 Apr
            • Re: [patch] plugin build process improvementsAntony Dovgal3 Apr
            • Re: [patch] plugin build process improvementsChad MILLER3 Apr
          • Re: [patch] plugin build process improvementsSergei Golubchik3 Apr
  • re: [patch] plugin build process improvementsMichael Widenius22 Mar
    • Re: [patch] plugin build process improvementsAntony Dovgal22 Mar