From adam at rosien.net  Thu Jan 31 10:55:32 2008
From: adam at rosien.net (Adam Rosien)
Date: Thu, 31 Jan 2008 07:55:32 -0800
Subject: [Revactor-talk] Bad domain in URLs of RSS feed
Message-ID: <cf67d0ac0801310755x10cb44c6tb861aee3a6920c61@mail.gmail.com>

Just a heads up - the Revactor RSS feed doesn't use revactor.org as
the domain of the entries.

.. Adam

From randyb at cloudscale.net  Thu Jan 31 15:21:14 2008
From: randyb at cloudscale.net (Randy Bias)
Date: Thu, 31 Jan 2008 12:21:14 -0800
Subject: [Revactor-talk] Securing Revactor Communications
Message-ID: <96B8037F-9B6B-47B9-9629-C2906134492A@cloudscale.net>

Hello,


	I haven't seen any emails yet, so I'll get things started.  The Actor  
model for concurrency programming solves some specific problems for  
us, but I'm concerned about inter-system communications.  We could  
perform encryption/signing within each Actor, but that feels both  
heavy weight and cumbersome.  Another model would involve leveraging  
an already secure transport mechanism between systems (e.g. SSL).  Yet  
another option would be to piggyback on an asynchronous messaging  
system that handles security and authentication (at least between  
systems).

	I have been thinking about the last option the most recently.  Does  
it make sense to consider XMPP for such a task?  Can the addressing in  
XMPP be overloaded to address Actors as endpoints?  It feels like it  
could and I can't discern a reason why this wouldn't make sense.

	Have any others given thought to this?


Regards,



--Randy



Randy Bias, Founder, CloudScale
(877) 636-8589, randyb at cloudscale.net




From randyb at cloudscale.net  Thu Jan 31 17:40:24 2008
From: randyb at cloudscale.net (Randy Bias)
Date: Thu, 31 Jan 2008 14:40:24 -0800
Subject: [Revactor-talk] Securing Revactor Communications
In-Reply-To: <c7e6b2b00801311333x45e00a52o511b5de59cdaacd7@mail.gmail.com>
References: <96B8037F-9B6B-47B9-9629-C2906134492A@cloudscale.net>
	<c7e6b2b00801311333x45e00a52o511b5de59cdaacd7@mail.gmail.com>
Message-ID: <149E9948-9E9C-45DB-BBA3-F5746E69C157@cloudscale.net>


On Jan 31, 2008, at 1:33 PM, Tony Arcieri wrote:
> On Jan 31, 2008 1:21 PM, Randy Bias <randyb at cloudscale.net> wrote:
> I haven't seen any emails yet, so I'll get things started.  The Actor
> model for concurrency programming solves some specific problems for
> us, but I'm concerned about inter-system communications.
> That's a big hairy issue we haven't begun to work out at all.  I've  
> been discussing this a little bit with MenTaLguY, and I get the  
> feeling it's something neither of us feel great about addressing.
>
> My inclination is to start with DRb as the basis for inter-Actor  
> communications, then investigate alternatives in the future.  For  
> example, interoperability with the distributed Erlang protocol would  
> be great, as you could build systems where Erlang and Ruby  
> interoperate using the distributed Actor protocol.  The Scala people  
> have already done this:
>
> http://www.theserverside.com/tt/articles/article.tss?l=IntegratingJavaandErlang

Interop with Erlang / Scala is appealing to me.  I don't have an  
immediate need, but it definitely feels important.

> Regardless I feel that encryption (if present) should be handled by  
> whatever's sending data to the wire, but for a number of use cases  
> no encryption will be needed whatsoever.

I agree.  Local Actor communications shouldn't be encrypted.  Most of  
our use cases are going to require a high degree of confidentiality.

> I have been thinking about the last option the most recently.  Does
> it make sense to consider XMPP for such a task?  Can the addressing in
> XMPP be overloaded to address Actors as endpoints?  It feels like it
> could and I can't discern a reason why this wouldn't make sense.
>
> I've seen interest lately in using XMPP as a general-purpose  
> asynchronous messaging protocol for cloud computing, e.g.:
>
> http://www.jivesoftware.com/community/blogs/jivetalks/2008/01/24/xmpp-aka-jabber-is-the-future-for-cloud-services

Yes.  We've been talking about it internally since last summer, but  
started with Ruby Reliable Messaging (RRM) for prototyping/ 
simplicity.  RRM turned out to be not so reliable.  Since our first  
RRM implementation XMPP seems very desirable.  We get a lot of 'free'  
functionality using it like encryption, authentication, store/forward,  
presence, etc.  And it appears like a well-vetted messaging system  
that deals well with unreliable networks.  We looked at AMQP, etc.,  
but many of the other competitors look like they assume the network is  
secure or reliable, which isn't ideal.

Our product is intended to be designed for hostile, unreliable, cloud  
fabrics.  XMPP seems ideal for that purpose.

> My take would be that while it could be used for a distributed Actor  
> protocol, it's far more complex than what's actually needed.

I'm also concerned about that and we have little experience with XMPP,  
but reading between the lines it looks like at least only minimal  
functionality is needed to start.

> My personal inclination remains the Erlang wire protocol, especially  
> as it could provide interoperability with both Erlang and Scala (as  
> well as other JVM-based languages)

This is something else I know little about.  Are folks able to wrap  
this in SSL?

When I'm thinking about the future of distributed computing, it seems  
pretty clear to me that it will be cross-firewall.  You might want to  
have part of your app on EC2 for elasticity reasons, for example.   
Having a clean cross-firewall protocol that includes encryption and  
authentication seems critical.

What would it take to go either route?  Either XMPP or Erland wire  
protocol?  What level of effort would be required?


Thanks,



--Randy



Randy Bias, Founder, CloudScale
(877) 636-8589, randyb at cloudscale.net

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/revactor-talk/attachments/20080131/176833a7/attachment.html