atom feed15 messages in org.torquebox.torquebox-user[torquebox-user] Help Shape the Futur...
FromSent OnAttachments
Ben BrowningOct 29, 2013 5:40 am 
Jonas NicklasOct 29, 2013 7:54 am 
Stanley,LeviOct 29, 2013 9:12 am 
Daniel PittmanOct 29, 2013 9:30 am 
Ben BrowningOct 29, 2013 9:31 am 
Jonas NicklasOct 29, 2013 10:25 am 
Saulius GrigaitisOct 29, 2013 10:37 am 
Rubem AzenhaOct 29, 2013 12:11 pm 
Ben BrowningNov 1, 2013 7:27 am 
Ben BrowningNov 1, 2013 7:33 am 
Ben BrowningNov 1, 2013 7:37 am 
Ben BrowningNov 1, 2013 7:50 am 
Topping BowersNov 1, 2013 9:00 am 
Tim UckunNov 3, 2013 7:25 pm 
Ben BrowningNov 6, 2013 8:00 am 
Subject:[torquebox-user] Help Shape the Future of TorqueBox
From:Ben Browning (bbro@redhat.com)
Date:Oct 29, 2013 5:40:57 am
List:org.torquebox.torquebox-user

Since the release of TorqueBox 3.0.0, the TorqueBox team has taken some time to think about and prototype where we want TorqueBox to be in the next couple of major releases compared to where it is now. We’ll get back to fixing 3.x bugs shortly, but we wanted to open up the discussion and gather community feedback about what you think the future of TorqueBox should look like.

So, let’s hear it. Anything is on the table for change, from the underlying tech we’re built on to the set of features and APIs we provide. Here are a couple of questions to think about as you provide feedback:

* What are the biggest development and/or production headaches with TorqueBox today?

* What features do you think are missing from TorqueBox?

* What features are included in TorqueBox that should be removed?

* What advantages do other servers have over TorqueBox? And vice-versa?

* Would you like a unified polyglot project that combines TorqueBox, Immutant (http://immutant.org), and perhaps others? Or does it make sense to keep things separated by language?

* What if TorqueBox were not based on an existing Java application server?

* Is the ability to deploy existing Java applications (.wars) important?

We have a couple of very high-level ideas that we think will make TorqueBox more compelling listed below, if you’d like to comment on those.

* embeddable with a small (< 10MB) download size for the TorqueBox core and necessary bits to serve Rack web applications

* a modular installation where only the features you need are downloaded and installed (perhaps encapsulated entirely as Rubygems vs only the Ruby API being contained in the gems like today)

* better support for browser-push (via WebSockets and more) and other future HTTP tech like SPDY and HTTP 2.0

* an easy way to extend TorqueBox itself, adding additional functionality or perhaps swapping out shipped implementations of things like our cache and messaging APIs for alternate ones

So let's hear it. Like I said, anything is on the table. What needs to happen to make TorqueBox the best choice for deploying Ruby applications?

Thanks,

Ben