in reply to Re^5: JETTERO tries to take over Net::IMAP::Simple on PAUSE
in thread JETTERO tries to take over Net::IMAP::Simple on PAUSE

I recognize you here and I respect you, but without this thread I might not have made the connection between ECARROLL and Evan Carroll. I would not have placed rcaputo at all. I know I'm poor at tracking attributions but I don't see how a name like POE<cpan:ecarroll> is more informative than POE_Fast or POE_Portable.

Yes, I am relatively unaffected by any current namespace disputes. I am further removed from CPAN than you. For a decade or more, I used Perl for small jobs and when I discovered CPAN, the task, as a rookie, of finding a module to do some task lacked any immediate payback. It can be easier to build a wheel than to find one.

I am further removed from CPAN than you; I don't pretend to know the intent or workings of authorities. I seek education:

I do realize that more toolchain learning issues will deter people from contributing to CPAN. That is bad but does allow a smaller group the chance of greater cooperative action.

Be well,

  • Comment on Re^6: JETTERO tries to take over Net::IMAP::Simple on PAUSE

Replies are listed 'Best First'.
Re^7: JETTERO tries to take over Net::IMAP::Simple on PAUSE
by EvanCarroll (Chaplain) on May 19, 2009 at 03:53 UTC
    Well, firstly. I'm not aiming for speed though I think I can make it faster, nor am I aiming for portability -- in fact I won't run on perl 5.6 at all. I'm aiming for a transparent POE framework that a novice can follow and use. I view poe as something everyone needs and should know, but is afraid to learn because the curve on learning it and getting used to it is entirely too steep. My goal is to broaden the audience by a factor of 10, or simply to get a new audience. This is also unique from the current maintainer, and developers, who simply don't seem to care about this goal at all. Now, onward with the questions.
    How do I as user determine which POE is the POE I've heard about?
    This is left to the interface guys. I imagine the most-authoritative will probably be determined through a karma system, or maybe most-downloaded, or maybe most-actively used in other cpan-modules. Just look at the official ruby on rails on github. It has 618 active forks. That doesn't mean its dieing, that means its thriving!! 618 people have examined the code, a great many of them have developed changes, and a great many of those will be merged back into the tree as part of the maintenance the maintainers must do. In github, anyone can hit a button to fork, and anyone can flag a maintainer with a notice he should pull from you or examine your code. No sane person would suggest those 618 people coordinate with one central-social point; nor would any sane person suggest they fork rails into a different name-space. When authorities are added, forking is even less hostile, this is always a good thing.
    Should I view the existence/publishing of both POE<cpan:rcaputo> and POE<cpan:ecarroll> as proof of some disagreement between the two authors?
    No, and it is rather silly to focus on the reason of the fork because it really doesn't and shouldn't matter. Forks are a good thing. To make such a statement -- should Ubuntu be viewed as a disagreement with Debian. No, thats an oversimplification: they've got different goals. Should the Ubuntu desktop be viewed as a sort of disagreement with upstream GNU Gnome desktop for having modified it? No, again, different goals. What is the official Linux kernel, is it the one on or the one with a specific distro's patchset? Well, it depends on which one is official for you, git made a mere social convention. Anyone can become the new Linux kernel, just convince people that you should be their authority.
    If not, how do I know which is the ephemeral package? ... If yes, how has the social problem been solved?
    That depends. Let's poke fun at myself: I have 0 respect for perls less than 5.8, and only marginal respect for perl 5.8. I'm the 5.10 guy. I use given/when statements. I use FieldHashes. I use state variables. And, I've only had them for a little over a year, but you're not getting my // or //= out of my hands easily... That is me.
    If you want clean code, that works for 5.10, then you would use my authority. If you want code that works for 5.00, rcaputo is probably your man. It isn't about being hostile, it is simply about me wanting modern good code in my system and not assmebly-like perl with binary slices, constant pollution, or "poe"-style components.
    If these authorities are of equal status, how should I not view this as the demolition of namespaces on CPAN?
    I'm not sure how to attack this -- I'm not even sure if I understand "demolition" here. My guess is you're referring to having multiple modules that publish code into the same ``perl name-space`` as a "demolition" of a cpan-namespace. A cpan namespace will have to consist of the cpan authority, and the perl-namespace, (and actually the version but lets skip over this detail).
    Other than that, your view of namespace-sanctity on cpan is probably a little off base. The official API of the vanilla POE demands you assume the kernel is in POE::Kernel. I mean, not just the constants for the indexes into the blessed arr but right now I'm working to make this stupid syntax work, with a modular POE::Kernel in POE::KernelX:  sub POE::Kernel::ASSERT_DEFAULT () {1}
    And, other things too on cpan destroy namespace sanctity. Look at POE::Resource::Events, or any POE::Resource, or POE::Loop which opens up the namespace of POE::Kernel. They all make bad assumptions, and don't understand what a namespace is. Moose::Roles fixed them good ;) Another example would be HTML::TreeBuilder::XPath which opens up HTML::Element and totally rewrites it - dangerous thing perl doesn't protect against, if you use this AND HTML::TreeBuilder in the same application. The whole state of cpan is a mess without authorities. with them the XPath guy could have just forked HTML::Element -- which despite having 24 bugs hasn't had a release in 3 years (he probably didn't want to bother with this task) -- but I'm ranting now because I have production code that uses this crap and I was trying to forget about it.

    Evan Carroll
    The most respected person in the whole perl community.