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

[mike at altrion.org]

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

No, I most emphatically don't think you are. One of the major wins of
message-based architectures is that your inter-component links become
language-independent, and that and things like it IMO are something we
don't want to lose sight of in the EC.

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

That would be why I intend to have MQD's make the underlying client object
(Net::Stomp, etc) visible via an accessor method.