Art, can we please just drop it? This horse is gone.
Let's go back and focus on the code. Looking forward to your contributions.
Hadrian


On 02/04/2014 10:38 AM, artnaseef wrote:
Hadrian,

I apologize for keeping the discussion alive, even when some of the
discussion may be painful.  With that said, can we continue to discuss it,
letting go of what's done?

My hope is that we can, as a community, decide on a path forward that
meets all of the needs and opens the door to go past that.  For example,
if someone wants to come improve the webconsole, it would be good to have
clarity on what is acceptible and not acceptible for such an effort.

I see James is frustrated, as are a lot of people passionate about
ActiveMQ and Hawt.io.  I'm getting frustrated just reading the comments!
I hope to see the frustration fade out and see it be replaced with action,
and keeping the passion for ActiveMQ alive!

-art


James, I believe you yourself suggested in a previous mail to stop this
conversation. I think it's the right thing to do as we now know where we
stand.

We understand that you are disappointed, we understand that the *only*
good solution is the technology you build outside the apartheid of the
ASF the place where one cannot innovate. You made your opinions
abundantly clear. It just so happens that we don't share your opinions.
You will not be convincing no matter how much you'll insist on this
tone. Therefore my strong suggestion is to either help contribute to fix
whatever you think is lacking with our AMQ console or just let us do it.

Cheers,
Hadrian



On 01/31/2014 07:21 PM, James Strachan wrote:
On Friday, January 31, 2014, artnaseef <[email protected]> wrote:

Another thing - "22Mb legacy turd" is not a technical argument (at
least, I
don't recognize it as one).
Memory usage is important to a message broker - which has to spool to
disk
as soon as it's out of RAM - which drastically affects performance. BTW
that 22mb turd is just the compressed disk size of the code, never mind
the
runtime overhead


I'm disappointed.
If there are concerns with maintenance, what are they?

No one wants to maintain it for one; it's been dormant for years; plus
it's
kinda crappy.

Second there's a much better solution now. Though It'll probably annoy
you
if I mention it out loud.

Third, jolokia is probably enough these days for runtime sevices (nice,
lean REST/JSON API to the mbeans). Any devops can knock
themselves out with any script/tool/web page with that.

BTW before the Savoir/Talend zealots jump in with further conspiracy
theories; jolokia isn't a Fuse/Red Hat project at all, we've no
committers.
It's just a great, lean solution to the management issue.


   I believe there are
currently only 3 outstanding Jira entries for the console.
Look closer. But to be honest the code's been neglected with little
community for so long, folks probably stopped raising anything but bugs
&
security issues many years ago



Right?  It's old
- so what, it's not older than ActiveMQ ;-).
It's not far off really - but key pieces of ActiveMQ get rewritten &
improved all the time (eg level db). The web console is the same old
crap
it's always been. I wrote quite a bit of it many years ago; I apologise
for
it profusely-  but it still deserves a sympathetic burial.

Maybe struts 1.0 is up for a comeback too?


I love that so many people are passionate about ActiveMQ.


Me too!



I wish that
passion were being put into making it better and moving it forward
Didn't you spot that quite a few of us have been putting our passion
into a
new amazing console for ActiveMQ, based on modern lightweight
technology - that's
not 21Mb of compressed turd?  Or do you just discount all open source
projects without an Apache PMC in principle without even looking?



rather
than making arguments without merit and laying out criticism - very
disappointing.
I'm disappointed you're disappointed



So, back to defining the problem.  All I've seen so far is the list of
security concerns from Hiram - thank you Hiram.  Anything else?  I do
believe I've read comments about difficulty maintaining it.  Is that
true,
or just an exaggerated expression of frustration?
When code is dying and losing its utility & before it's buried in the
Attic, the compassionate thing to do is see if it can survive without
life
support. Moving it to a sub project seems the right thing to do. If you
can
attract a community around it - great, fair play to you. If not, the
attic
is ok too (most code will end up there one day, it's just a question of
time).

Apache is all about communty and right now I don't see any around the
old web console code. Moving it to a sub project will settle the
argument
once and for all in a fair, Apache Way. Whatever the outcome, the
community
wins




--
View this message in context:
http://activemq.2283324.n4.nabble.com/ActiveMQ-Console-let-s-get-the-problem-defined-tp4677105p4677224.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.





_______________________________________________
If you reply to this email, your message will be added to the discussion
below:
http://activemq.2283324.n4.nabble.com/ActiveMQ-Console-let-s-get-the-problem-defined-tp4677105p4677404.html
To start a new topic under ActiveMQ - Dev, email
[email protected]
To unsubscribe from ActiveMQ Console - let's get the problem defined,
visit
http://activemq.2283324.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4677105&code=YXJ0QGFydG5hc2VlZi5jb218NDY3NzEwNXwtMjA1NDcyNjY5MQ==




--
View this message in context: 
http://activemq.2283324.n4.nabble.com/ActiveMQ-Console-let-s-get-the-problem-defined-tp4677105p4677406.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.

Reply via email to