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

[Rocco Caputo]

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?

> First off: XML
>
> The main problem I see here for the core is it's a massive problem  
> space
> with multiple solutions, as a quick CPAN search reveals. I think  
> perhaps
> our first step needs to be to try and analyze the problem space into
> categories of solution (parse vs generate, straight mapping to/from  
> a data
> structure vs XPath-based vs tree walking), and start with a document
> that's a guide to best practices for each as we see them. Thoughts?

Defining the problem space is a good way to start when the problem is  
broad and nebulous.

I keep coming back to XML::LibXML at work, but I admit that I've  
written abstractions for it.  Unfortunately they're also at work, so  
they're neither public nor generally useful.

> Next: Packaging

I'm weak in this area.  CPAN has been sufficient for me, and PAR seems  
to work for POE's users when nearly all else fails.

> 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.

-- 
Rocco Caputo - http://poe.perl.org/