WG: [maglev-discussion] Rails 3.2 released

[Tim Felgentreff]

Forgot to copy the list...

Sent from my mobile, please excuse me for being brief.
Von: Tim Felgentreff
Gesendet: 20.01.2012 22:05
An: Michael Latta
Betreff: AW: [maglev-discussion] Rails 3.2 released
Afaik that will depend as much on contributions as it does on the VM
people. Most of Maglev is in Ruby (in fact, lots of it was imported
from Rubinius' codebase), so pulling Rubinius' 1.9 support could be a
good start. Things that can't be done by contributions alone would be
adjustments to the parser and encoding support, I guess.

Sent from my mobile, please excuse me for being brief.
Von: Michael Latta
Gesendet: 20.01.2012 21:27
An: maglev-d...@googlegroups.com
Betreff: [maglev-discussion] Rails 3.2 released
3.2 is the last release to support 1.8.7. What is the plan to support
1.9 in maglev?

Michael

--
You received this message because you are subscribed to the Google
Groups "MagLev Discussion" group.
To post to this group, send email to maglev-d...@googlegroups.com.
To unsubscribe from this group, send email to
maglev-discuss...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/maglev-discussion?hl=en.

[Jesse Cooke]

I've asked Monty the same thing. I think a lot depends on how much the community is willing & able to contribute. The best way to get 1.9 support is to use MagLev as is! Showing VMWare that we want more resources on MagLev because we actually use it is likely the only way to get those resources.

--------------------------------------------
Jesse Cooke :: N-tier Engineer
jc00ke.com / @jc00ke

[ecin]

And for that we need a reliable way to deploy Maglev apps, a la Heroku. 

[Michael Latta]

MagLev support in cloud foundry would go a long way.  Any word on that?

Michael

[Conrad Taylor]

Sent from my iPhone

On Jan 20, 2012, at 1:25 PM, Jesse Cooke <je...@jc00ke.com> wrote:

I've asked Monty the same thing. I think a lot depends on how much the community is willing & able to contribute. The best way to get 1.9 support is to use MagLev as is! Showing VMWare that we want more resources on MagLev because we actually use it is likely the only way to get those resources.

Jesse, this definitely isn't ideal when many applications are on Ruby 1.9 or planning to migrate to Ruby 1.9. There have been many API changes going from 1.8.7 to 1.9.3 and Ruby 2.0 is currently in the works.  Thus, asking your clients to downgrade to use Maglev, is a very tall request indeed. On a side note, is anyone planning on presenting the benefits of using Maglev at the upcoming Railsconf 2012?  Last but not least, I would like to see Maglev evolve and I'm also open to contributing

to the project.

Think different and code well,

-Conrad

[Conrad Taylor]

Sent from my iPhone

On Jan 20, 2012, at 1:22 PM, Tim Felgentreff <timfelg...@gmail.com> wrote:

> Forgot to copy the list...
>
> Sent from my mobile, please excuse me for being brief.
> Von: Tim Felgentreff
> Gesendet: 20.01.2012 22:05
> An: Michael Latta
> Betreff: AW: [maglev-discussion] Rails 3.2 released
> Afaik that will depend as much on contributions as it does on the VM
> people. Most of Maglev is in Ruby (in fact, lots of it was imported
> from Rubinius' codebase), so pulling Rubinius' 1.9 support could be a
> good start. Things that can't be done by contributions alone would be
> adjustments to the parser and encoding support, I guess.

In addition to what Tim is saying, I have a crazy thought:

Would VMWare consider extracting the Ruby specific pieces out of Gemstone/S into an open source editable library? This library would depend on Gemstone/S for building but allow contributors to move the Ruby byte code forward as well as the associated Ruby code.

Think different and code well,

-Conrad

>

[Michael Latta]

It is my understanding that all the source is open other than the released Gemstone/S64 system. I believe the "build" process is in the github repository so you can build the entire system from scratch on top of Gemstone/S 64. Of course there have been changes to Gemstone to support MagLev. The bigger issue to me is that currently MagLev requires a custom hosting environment which negates some of the operational value. With vendors like Heroku or EngineYard I just pay a monthly fee and the ops part is taken care of, with on demand support people. With MagLev I would need to provide 24/7 ops support and be a full sysadmin. Even though the technical value is there in MagLev the business case is much harder to make. Once it is integrated with Cloud Foundry there will be commercial offerings that support it.

Michael

[Conrad Taylor]

Sent from my iPhone

On Jan 20, 2012, at 3:13 PM, Michael Latta <mla...@technomage.com> wrote:

> It is my understanding that all the source is open other than the released Gemstone/S64 system. I believe the "build" process is in the github repository so you can build the entire system from scratch on top of Gemstone/S 64.

Thanks for the information because this makes it much easier to enhance Maglev to satisfy technology demands of a project.

> Of course there have been changes to Gemstone to support MagLev. The bigger issue to me is that currently MagLev requires a customs hosting environment which negates some of the operational value. With vendors like Heroku or EngineYard I just pay a monthly fee and the ops part is taken care of, with on demand support people.

Heroku and Engine are great services as well as the bare-bones AWS. The major advantage is that they provide flexibilty for spinning up/down new server instances with a minor cost in operational overhead.

However, I had to setup several servers from scratch which were challenging but it allowed me greater level of customizations, learned a lot about server administration, overall performance was much better, and it was much cheaper especially when compared to Heroku and Engine yard.
Your mileage will vary depending the project's requirements.

Lastly, I tend to use Heroku for web site staging and testing for clients but when you want to scale, it becomes costly and other options will be better.

[Jesse Cooke]

On Fri, Jan 20, 2012 at 2:45 PM, Conrad Taylor <conr...@gmail.com> wrote:

Sent from my iPhone

On Jan 20, 2012, at 1:25 PM, Jesse Cooke <je...@jc00ke.com> wrote:

I've asked Monty the same thing. I think a lot depends on how much the community is willing & able to contribute. The best way to get 1.9 support is to use MagLev as is! Showing VMWare that we want more resources on MagLev because we actually use it is likely the only way to get those resources.

Jesse, this definitely isn't ideal when many applications are on Ruby 1.9 or planning to migrate to Ruby 1.9. There have been many API changes going from 1.8.7 to 1.9.3 and Ruby 2.0 is currently in the works.  Thus, asking your clients to downgrade to use Maglev, is a very tall request indeed. On a side note, is anyone planning on presenting the benefits of using Maglev at the upcoming Railsconf 2012?  Last but not least, I would like to see Maglev evolve and I'm also open to contributing

to the project.

I personally wouldn't ask a client to "downgrade" but I would definitely consider in other aspects of a system, such as the API endpoint that web, mobile web and native apps communicate with.

I haven't heard of any planned presentations, but it would be really cool to see one!