IMHO an architectual, pluggable and open approach is preferred over
trying to include everything into a single package. What if users
don't want or need a feature in their Ofbiz installation? What if
there's a better solution?
My personal favor would be to use a branch as long as possible and
merge
Yes, I see your point, and it's a good one. It would be better implemented in a
replaceable and configurable way.
-David
On Dec 15, 2009, at 6:29 PM, Adrian Crum wrote:
> No, I'm not saying I want to work on it. No, I'm not trying to force anyone
> to do anything.
>
> The subject of the thr
No, I'm not saying I want to work on it. No, I'm not trying to force
anyone to do anything.
The subject of the thread is ESME implementation. I'm sharing ideas on
that subject. I'm making suggestions. I'm providing examples of how
similar features in OFBiz were implemented previously.
-Adria
Just to be clear, are you saying you want to work on this?
Please keep in mind that people are free to contribute what they will. Maybe we
can vote or all agree on not allowing something in, but we can't force anyone
to do anything. We also shouldn't, though many of us often do, imply that
oth
Developing support for it would be fine, if the messaging feature was
set up as a gateway.
I'm not aware of any generic specifications for payment gateways, yet
OFBiz accommodates a variety of them.
The point I have been trying to make is this: if we're going to add an
instant messaging or t
Then you'll have to develop support for it, or get someone else to do it for
you.
I'm not aware of any generic specification we could implement to that would
support ESME as well as other options. Is there one you have in mind?
-David
On Dec 15, 2009, at 5:42 PM, Adrian Crum wrote:
> What i
What if I want the messaging feature, but I already have a messaging
server that isn't ESME?
-Adrian
Hans Bakker wrote:
we are still investigating how to interface but yes an inclusion of a
full system as a component seems the best way to us if only for the ease
of installation and the conveni
I agree it would be easier to include it, especially if it is going to be used
for OOTB functionality (like system messages, customer support chat (sync or
async), other things Hans mentioned before, etc).
It would be nice (maybe necessary?) to make sure that an external instance of
ESME can b
On 16/12/2009, at 12:30 PM, Hans Bakker wrote:
looking more into skala . an possible upgrade to groovy and java
being compatible with our current runtime environment (JVM/Tomcat)
Scala is very different from java or groovy language-wise, adding
support for it would be fine but I don't th
we are still investigating how to interface but yes an inclusion of a
full system as a component seems the best way to us if only for the ease
of installation and the convenient license.
looking more into skala . an possible upgrade to groovy and java
being compatible with our current runtime
In other words, "Thank you for your suggestions, but I'm going to ignore
them."
Saying ESME is an essential part of OFBiz is like saying Apache James is
an essential part of OFBiz - so we can send emails from OFBiz.
No, we don't need to install ESME - just create a gateway to it. The
integra
Sounds like a plan but then we will get tied to ESME, maybe not so bad.
So no real opininon, though replacing the system info notes (wich is really a
good idea) needs maybe something more rooted in OFBiz.
Jacques
From: "Hans Bakker"
Hi everybody who commented.
The approach that Adrian has be
Hi everybody who commented.
The approach that Adrian has below and is supported by others in the
community was also our first and seems the easiest from an
implementation point of view.
After some investigation however we consider ESME not only an add-on but
an essential part of OFBiz which shou
13 matches
Mail list logo
