[Epo-ec-advisors] Some thoughts on areas to address in the EC

[Chris Prather]

On Thu, Jul 16, 2009 at 12:35 PM, Rocco Caputo<rcaputo at pobox.com> wrote:
> On Jul 16, 2009, at 06:20, mike at altrion.org wrote:
>
>> Partly thinking aloud here - my back's broad, so feel free to shoot me
>> down...
>
> I also have a thinking-aloud question.  Has anyone done a post-mortem on
> P5EE?  Why did it die?  Is there anything of value on the body?

I haven't seen anything official. My *personal* take on it (and one that
influences the directions I'm trying to have us take here) is that it failed
because it was trying to come up with one single solution that was entirely
new code. To me it seems better to pick exiting modules out of
CPAN that are emerging as best of breed and try to give them the help they
need to be the obvious choice.

TIMTOWTDI is a powerful tool for generating new ideas it needs tempering
however. Stevan Little took to saying But Sometimes Consistency Is Not A Bad
Thing Either (BSCINABTE) when people came with more features and ideas for
Moose that were radically different from how things already worked. (Also I
really like the image of Bicarbonate being used to sooth the acid of
TIMTOWTDI.)

[…]

>> Finally, Messaging...
>>
>> By which I mean XMPP, AQMP, Stonk, Amazon SQS and other ways of passing
>> messages between components of an enterprize app. There are modules for
>> most of the above, in various states of completion, several of which need
>> some love. On top of that, I'm working on MQI (Message Queue Interface),
>> which is intended to be DBI for messaging with a standard API via a
>> factory class and MQD (driver) layers on top of each protocol. Thoughts?
>> Does that sound like a good way forward?
>
>
> I think an abstraction layer is interesting and useful here.  In my
> experience, Perl comes in after an infrastructure is already chosen.  For
> example, management likes a particular buzzword, a company has an existing
> vendor contract, or a project is mainly in some other language so Perl
> bindings are an afterthought.  These sorts of projects will look elsewhere
> if the wrong transport layer is recommended.
>
> Am I off-base considering non-Perl project integration?  I can stop.  What
> are the ground rules?
>
> An API layer must allow access to unique features in the underlying message
> queue.  Projects will look elsewhere if an API hides a necessary
> interoperability feature.
>
> Various DBD modules expose each database's quirks.  Your MQI/MQD model
> implies you'll do the same, which I think is a good thing.  There is social
> pressure to use generic xxI features when possible, and dip into xxD's bag
> of quirks as needed.

My only experience here is having built one, and deciding based on that
experience that buiding your own message queue is a Fools errand so when the
option came up a second time we bought (Beanstalkd). Having a standard
interface would be wonderful eventually, and if people agree it certainly is
something I could see reccomending the EPO allocate funds towards.

-Chris