Bug #85677 for signatures: core only namespace

Tue May 28 12:06:56 2013 petercmartini [...] gmail.com - Ticket created

Subject:	core only namespace
Date:	Tue, 28 May 2013 12:06:41 -0400
To:	bug-signatures [...] rt.cpan.org
From:	Peter Martini <petercmartini [...] gmail.com>

As part of my project to include sub signatures into the perl core, the natural namespace to use - signatures - is already used. The defaults provided by signatures.pm are the same as what I've been working to include in core, but the extension mechanism (in my opinion) wouldn't be appropriate for core, and the guts would need to be re-implemented for better integration and to get rid of any other CPAN dependencies. I propose moving the extension API of signatures to Signatures, and trimming down signatures to a shape suitable for core distribution, with a soft dependency on Signatures if those (CPAN only) features are desired. Thoughts?

Tue May 28 13:16:01 2013 ether [...] cpan.org - Correspondence added

Subject:	Re: [rt.cpan.org #85677] core only namespace
Date:	Tue, 28 May 2013 10:15:41 -0700
To:	Peter Martini via RT <bug-signatures [...] rt.cpan.org>
From:	Karen Etheridge <ether [...] cpan.org>

On Tue, May 28, 2013 at 12:06:57PM -0400, Peter Martini via RT wrote: Show quoted text

> I propose moving the extension API of signatures to Signatures, and > trimming down signatures to a shape suitable for core distribution, > with a soft dependency on Signatures if those (CPAN only) features are > desired.

Having modules or distributions with the same case-insensitive name is a not very good. http://www.nntp.perl.org/group/perl.modules/2013/02/msg84770.html http://blogs.perl.org/users/neilb/2013/02/pause-permissions-should-be-case-insensitive.html How about moving off non-core functionality into plugins/extensions in the same namespace?

Tue May 28 13:16:02 2013 The RT System itself - Status changed from 'new' to 'open'

Tue May 28 13:50:10 2013 petercmartini [...] gmail.com - Correspondence added

Subject:	Re: [rt.cpan.org #85677] core only namespace
Date:	Tue, 28 May 2013 13:49:48 -0400
To:	bug-signatures [...] rt.cpan.org
From:	Peter Martini <petercmartini [...] gmail.com>

On May 28, 2013 1:16 PM, "Karen Etheridge via RT" < bug-signatures@rt.cpan.org> wrote: Show quoted text

> > <URL: https://rt.cpan.org/Ticket/Display.html?id=85677 > > > On Tue, May 28, 2013 at 12:06:57PM -0400, Peter Martini via RT wrote:

> > I propose moving the extension API of signatures to Signatures, and > > trimming down signatures to a shape suitable for core distribution, > > with a soft dependency on Signatures if those (CPAN only) features are > > desired.

> > Having modules or distributions with the same case-insensitive name is a > not very good. > > http://www.nntp.perl.org/group/perl.modules/2013/02/msg84770.html >

http://blogs.perl.org/users/neilb/2013/02/pause-permissions-should-be-case-insensitive.html Show quoted text

> > How about moving off non-core functionality into plugins/extensions in the > same namespace? > >

Do you mean something like signatures::api ?

Fri Jun 14 13:53:56 2013 ether [...] cpan.org - Correspondence added

I created a branch on github to get this started -- https://github.com/karenetheridge/signatures/tree/topic/api_split However I don't think I can simply move the implementation methods, without breaking some of the XS code? I can assist much more with this - I just don't want to break anything :)

Fri Nov 29 13:30:32 2013 PCM [...] cpan.org - Correspondence added

RT-Send-CC:

ether [...] cpan.org

On Fri Jun 14 13:53:56 2013, ETHER wrote: Show quoted text

> I created a branch on github to get this started -- > https://github.com/karenetheridge/signatures/tree/topic/api_split > > However I don't think I can simply move the implementation methods, > without breaking some of the XS code? > > I can assist much more with this - I just don't want to break anything > :)

I'm coming back to this part of it after way too long, so, sorry about that :-) What I was thinking was essentially moving this whole namespace to a new module, maybe signatures::BHooks instead of signatures::api, and then changing signatures to essentially delegate everything to signatures::BHooks if perl version < X, where perl version X would be where (hopefully) signatures is bundled into core and wouldn't ship with signatures::BHooks. I don't know how to express that kind of dependency in Makefile.PL though!