Hi Henrik,
Le 26 sept. 2011 à 02:05, Henrik Ingo a écrit :
> docs/ ?
>
> There are doxygen source code comments, but what about end user
> documentation? Where should I expect to find it? How will you group
> documentation for this plugin together with other authentication
> related plugins and possible non-plugin related authentication
> sections in the manual? I'm asking because I'm documenting my plugin
> too.
For user plugin docs, eventually I'd like to group the Plugins list by types of
plugins, like:
Plugins
*********
Authentication
===========
* Auth All
* Auth PAM
* Auth Schema
Functions
========
* String Functions
* Utility Functions
Protocols
=======
* Drizzle Protocol
* MySQL Protocol
I think that's logically organized. Some plugins are actually modules that
provide many things, but the vast majority fall into simple categories.
> namespaces?
>
> What should we use for namespaces for plugin code? I took example from
> a plugin that is recent and written by a Drizzle authority figure:
> json_server. It uses this:
> ...
> And other modules use some other variations, there is no standard as
> far as I can see. Should there be a standard? (FWIW, if I had just
> picked something myself, I would have used
> namespace plugin { namespace plugin_name {
> )
I've wondered this too. I think a core developer should update the coding
standards wiki with a section about which namespaces to use.
> System tables?
>
> Drizzle doesn't have a system schema like MySQL has mysql.*. You have
> chosen to create a schema called auth and put your table in there.
> Wouldn't it be better to have a system schema where all such tables
> are located. I propose to call such a schema system.* and thus your
> table would be called system.auth. (I have my own need in that I may
> need to create system tables for stored procedures and triggers,
> although it might be better to store them inside the user's schema
> instead...)
I like that idea; I'm for it if everyone else is. I chose the let the user
decide where to put the auth table for this reason, as you stated: Drizzle
doesn't have a specific system table. Also, I thought I would leave it to the
user to do the correct or clever thing in creating the table. Maybe, for
example, the user wants the auth table to be ENGINE=Memory; who knows. Also,
maybe they want to change the auth table, so I made auth_schema_table a dynamic
variable. Eventually I'd like to add a cmd line option
--auth-table.create-table that will create a basic auth table for the user. In
general, I try to balance flexibility and ease-of-use.
Thanks for your feedback,
Daniel
> On Mon, Sep 26, 2011 at 4:48 AM, Daniel Nichter <[email protected]> wrote:
>> Drizzle developers,
>>
>> I created and pushed auth_schema for
>> https://bugs.launchpad.net/drizzle/+bug/738601. It's simple but functional
>> (and tested and documented). Any feedback? I still need to add some code
>> comments and credits (e.g. to Eric Day since I took and modified
>> verifyMySQLHash from his auth_file plugin). Else, I will propose to merge
>> it soon.
>>
>> Thanks,
>>
>> Daniel
>>
>> P.S. "auth_schema" instead of "auth_db" since Drizzle is trying to use the
>> term "schema" instead of "database".
>> _______________________________________________
>> Mailing list: https://launchpad.net/~drizzle-discuss
>> Post to : [email protected]
>> Unsubscribe : https://launchpad.net/~drizzle-discuss
>> More help : https://help.launchpad.net/ListHelp
>>
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
