openstack team mailing list archive
Mailing list archive
Re: Queue Service, next steps
Personally, I'd prefer C++ since that's what I'm used to, but I'd be
open to learning Erlang, too. Been wanting to learn it for a while
On Fri, Feb 18, 2011 at 1:11 AM, Eric Day <eday@xxxxxxxxxxxx> wrote:
> Duck farm? :)
> Are you two concerned about building a developer community around a
> project in Erlang? I'm all for going that route if other folks are
> comfortable with it.
> I also have some concern around the speed of Erlang. It's great,
> especially if you know what primitives can be expensive and how to
> tame beam, but it will always be slower (sometimes significantly)
> that C/C++ for some tasks.
> On Thu, Feb 17, 2011 at 03:26:09PM -0800, Joshua McKenty wrote:
>> +1 for Erlang, as long as we have a duck farm.
>> On Thu, Feb 17, 2011 at 2:25 PM, Devin Carlen <devin.carlen@xxxxxxxxx>
>> I'll put in a +1 for Erlang as an OpenStack supported platform. We'd be
>> able to write a stable queue with a much more concise code base, and
>> this is project would be a great fit for Erlang.
>> On Feb 17, 2011, at 2:21 PM, Eric Day wrote:
>> > Thanks to everyone who gave great feedback on the first queue service
>> > thread. I've updated the wiki page to include the suggestions.
>> > http://wiki.openstack.org/QueueService
>> > With a decent vision of what we want to build, the next step is
>> > figuring out how. In a previous thread it was suggested that the
>> > preferred languages for OpenStack projects are Python, C, and
>> > C++. Since there is an emphasis on speed and efficiency for the
>> > queue service, I suggest we use C++. I expect this service to be
>> > CPU bound and would benefit being able to leverage multiple cores
>> > efficiently (within the same process), so I don't think Python
>> > is a good fit. I think C++ is a better fit than C due to the need
>> > for modular interfaces. While this can obviously be done in C, C++
>> > APIs are more concise and much less error prone. The OO style will
>> > also make it easier for Python developers who also want to learn and
>> > assist with C++ projects.
>> > Erlang is not on the preferred lists, but I would also put it out
>> > there as an option. While it may be a great fit for a project like
>> > this, I worry it won't attract the developer resources since Erlang
>> > isn't really a first-class language yet.
>> > If we decide to take the C++ path, I propose using a modular
>> > application framework I've been working on over the past year (mostly
>> > in my spare time). It provides a simple module programming interface
>> > with dependency tracking (kind of like Linux kernel modules). It
>> > already provides a multi-threaded event module (currently based on
>> > libevent, but this is pluggable) with simple networking abstractions
>> > built on top of it. We should be able to dive in an start writing the
>> > HTTP protocol module and queue processing modules. You can check out
>> > the current project at:
>> > https://launchpad.net/scalestack
>> > http://scalestack.org/
>> > The intention of using a framework like this is so we can easily reuse
>> > the other modules (auth, HTTP, logging, ...) for other OpenStack
>> > services in the future. Much like we use Eventlet, WSGI, etc. (and
>> > eventually openstack-common) for Python, we could prefer using the
>> > modules in Scale Stack for lower level projects.
>> > Thoughts?
>> > -Eric
>> > _______________________________________________
>> > Mailing list: https://launchpad.net/~openstack
>> > Post to : openstack@xxxxxxxxxxxxxxxxxxx
>> > Unsubscribe : https://launchpad.net/~openstack
>> > More help : https://help.launchpad.net/ListHelp
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openstack
>> More help : https://help.launchpad.net/ListHelp
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp