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

[Chris Prather]

On Thu, Jul 16, 2009 at 6:20 AM, <mike at altrion.org> wrote:
> Partly thinking aloud here - my back's broad, so feel free to shoot me
> down...
>
> 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?

>From my experience (limited hands on, but a member of the AxKit community for
going on 8 years now) this really comes down to use XML::LibXML, XML::SAX (and
a few helper modules like XML::Generator::PerlData and XML::SAX::Writer) and
possibly XML::Twig. I'm *personally* working on an XML::Toolkit that leverages
XML::SAX for marshaling XML to and from Moose objects but it's not emerged yet
as a clear generic "solution". I am updating Task::Kensho to include these
modules.

If someone has had different experiences I'm all ears. It isn't set in stone
until the end of this month/beginning of next when I go to make a
Task::EPO::EC.

> Next: Packaging
>
> Close to my heart, this one, as my current project is going to require me
> to hand over an installable Perl 'package' on potentially multiple OS's to
> largely indifferent siteops for installation. It seems to me the main two
> likely candidates (ignoring per-OS packaging) are either PAR or something
> clever involving local::lib. PAR handles cross-platform packaging, it just
> never seems to have got the leverage and momentum, which is a shame when
> you consider the likes of .jar/.war for Java, and .egg for Python.

Also not to be ignored here is BestPractical's Shipwright as well. This is a
domain that certainly needs to be addressed from what I can tell listening to
many many many people complain about it.

> 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 have no experience here.

-Chris