I was navigating through the staged website now.. it feels very
accurate and factual to me.. (sticking to the facts I think it's the
word I'm looking for here).


it's avoiding making any "mission statements" and it's just presenting
the projects..

IMO: We should go with the way it is now.. nice job!!!  We can always
improve it later.

On Tue, Mar 5, 2019 at 8:37 AM 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



-- 
Clebert Suconic

Reply via email to