The project is just ActiveMQ, so if going back to the earlier
statement I'd suggesting tweaking it, e.g something like
s/projects/components/:

"A SUITE OF OPEN SOURCE COMPONENTS FOR HIGH PERFORMANCE MESSAGING”

I dont really have a preference between the two statements, but I
would perhaps drop "broker" from the end of Justins, giving just:

"Flexible & Powerful Open Source Multi-Protocol Messaging"

Robbie

On Tue, 5 Mar 2019 at 13:43, Clebert Suconic <[email protected]> wrote:
>
>  I really like Martyn’s statement. TBH.
>
>
> On Mon, Mar 4, 2019 at 5:07 PM michael.andre.pearce
> <[email protected]> wrote:
>
> > I am just against making it seem we are exclusively broker only. Present
> > it maybe. But past it wasnt and future i hope it isnt.Happy for an
> > alternative. But atm i much prefer keeping it as Martyn had it.Sent from my
> > Samsung Galaxy smartphone.
> > -------- Original message --------From: Justin Bertram <
> > [email protected]> Date: 04/03/2019  20:53  (GMT+00:00) To:
> > [email protected] Subject: Re: Website But where is the "suite" of
> > projects?  The only things under activedevelopment/maintenance are the
> > brokers.JustinOn Mon, Mar 4, 2019 at 2:46 PM Michael André
> > Pearce<[email protected]> wrote:> Thats kind of why i
> > really liked the original tag line Martyn had:>> "A SUITE OF OPEN SOURCE
> > PROJECTS FOR HIGH PERFORMANCE MESSAGING”>> Its bang on what the ActiveMQ
> > community is about, for me.>>> > On 4 Mar 2019, at 20:31, Justin Bertram <
> > [email protected]> wrote:> >> >> > I don't think "provider" is a good
> > word at this point as it connotes some> > kind of service (e.g. a "cloud
> > provider") and may be confusing.  I think> > "server" and "broker" would
> > work fine as I don't think either of these> > exclude the inclusion of a
> > client (e.g. "Java Application Server"> > implementations have always
> > shipped various clients for remote EJB, JNDI,> > etc.). In my opinion, the
> > term "platform" connotes a place where you run> > your application code,
> > which ActiveMQ is not. There are certainly places> > for user code to run
> > (e.g. interceptors, plugins), but that code is to> > serve the broader
> > purpose of the server/broker as an integration point.> > Then again, maybe
> > my opinion is in the minority. I'm willing to be> > convinced. Perhaps
> > there are other good options we aren't considering.> >> > I don't want to
> > artificially limit where the project can go in the> future,> > but I also
> > want to call it what it is and it hasn't really departed from> > its
> > historical legacy.>>
>
> --
> Clebert Suconic

Reply via email to