The usual problem with copying Akka design is:

var ref = system.actorFor(path);


The above line violates object capability security model 
(see: http://en.wikipedia.org/wiki/Object-capability_model). It's a known 
and admitted problem of Akka actors. It is very convenient for development, 
and it severely complicates any sort of security if one desires it.

Another way to think of it, that line ensures that I can have no private 
actors. That's an equivalent of removing private objects/variables that we 
tend to rely on when writing JavaScript closures. It also ensures that I 
have no encapsulation at actor configuration level. 

On Thursday, September 26, 2013 12:49:45 PM UTC-5, ajlopez wrote:
>
> Hi people!
>
> I don't know enough about Akka actors, Alexei. But in my pet project:
>
> - no callback, you send a message to an actor reference, and voila
> - no threads, only use the force of Node.js ;-) as usual, it leverages any 
> async i/o processing
>
> I don't like to refer an actor by name (including machine, tree node, 
> etc...). I would like to refer an actor by role, or something alike. But 
> apparently, a lot of docs/examples are available for Akka, so my first 
> experiment is using the same ideas from Akka. Last time I see, Akka is 
> moving to have a cluster of agents, so you don't send a message to AN 
> agent, but to a cluster of possible duplicated agents.
>
> More experiments (including sending message, without knowing with part 
> will be attend the message, it is decided by configuration, not in your 
> agent/sending module code)
>
> http://ajlopez.wordpress.com/2013/05/30/aplicaciones-distribuidas-y-node-js/
>
> Messaging is the key, send the message, the force it will process, Luke ;)
>
> Angel "Java" Lopez
> @ajlopez
>
>
>
> On Thu, Sep 26, 2013 at 2:39 PM, Alexey Petrushin 
> <[email protected]<javascript:>
> > wrote:
>
>> > Akka system
>>
>> As far as I know Akka isn't true actor framework. It offer two ways
>>
>> - Actors backed by threads - simple to use, but not good for performance
>> - Asynchronous actors - good performance but hard to use (same async 
>> stuff, with same callback hell and other problems).
>>
>> True actor - when you have both - synchronicity and performance, Akka 
>> can't provide it.
>>
>> On Wednesday, September 25, 2013 5:32:23 PM UTC+4, ajlopez wrote:
>>
>>> Interesting thread, lot of good resources and discussion
>>>
>>> Since my past year email, I updated my pet project, to reflect more a 
>>> (very) simplified Akka system:
>>>
>>> https://github.com/ajlopez/**SimpleActors<https://github.com/ajlopez/SimpleActors>
>>>
>>> Angel "Java" Lopez
>>> @ajlopez
>>>
>>>
>>>
>>> On Wed, Sep 25, 2013 at 10:25 AM, Matthew Browne <[email protected]>wrote:
>>>
>>>>  On 9/25/13 9:06 AM, Alexey Petrushin wrote:
>>>>
>>>> I'd personally prefer actor to reactor because it's simpler to use. For 
>>>> me working with isolated independent things is much simpler than with 
>>>> state 
>>>> machine and recursions.
>>>>
>>>> I agree. Events can help prevent callback pyramids to some degree, but 
>>>> with actors you can write code just as if it were synchronous; it's just 
>>>> simpler.
>>>>
>>>> In terms of the API for a new actors library for node.js, I was 
>>>> thinking of something similar to this Ruby library:
>>>> http://celluloid.io/
>>>>
>>>> That library uses threads, but the same author previously wrote a 
>>>> library implemented using fibers, which could serve as a model for node.js 
>>>> (since obviously we don't have or want threads):
>>>> https://github.com/tarcieri/**revactor<https://github.com/tarcieri/revactor>
>>>>
>>>>  On 9/24/13 1:56 PM, Norman Paniagua wrote:
>>>>  
>>>> Thanks for the resources… 
>>>>
>>>>  I read somewhere in this groups that c extensions may slow down 
>>>> nodejs, and fibers just is written in c++, don't know yet how it may 
>>>> affect 
>>>> the performance of the app that uses it.
>>>>
>>>>  Thanks for mentioning this. There's at least one significant framework 
>>>> already using fibers (Meteor) and I haven't heard anything about it being 
>>>> slow, but we should keep this in mind because it would be ideal if the 
>>>> actor library were just as fast as native node.js.
>>>>
>>>>   
>>>> On Wednesday, July 24, 2013 9:17:24 AM UTC+4, Matthew Browne wrote: 
>>>>>
>>>>> Hi,
>>>>> I realize this thread is a little old, but I just came across it I 
>>>>> don't understand your reasoning...yes, Reactor (event loop-based 
>>>>> approach) 
>>>>> is a different approach than Actors, but Actors have been implemented 
>>>>> successfully on top of event loops in some other languages like Python 
>>>>> and 
>>>>> have achieved very good concurrent performance (from what I can gather 
>>>>> anyway).
>>>>>
>>>>> The main drawback is that you no longer have parallelism across 
>>>>> multiple cores, but in node.js we've already accepted that and are 
>>>>> willing 
>>>>> to settle for separate OS processes instead.
>>>>>
>>>>> The only real disadvantage I can think of is that the node.js API is 
>>>>> designed to be used with callbacks, but for one's own application code 
>>>>> (especially the parts that are straight JS that don't use the node API as 
>>>>> much) it seems like an actors library like drama 
>>>>> <https://github.com/stagas/drama>is a great approach to concurrency 
>>>>> (and asynchronous OOP).
>>>>>
>>>>>
>>>>> On Monday, June 18, 2012 11:50:41 AM UTC-4, Alexey Petrushin wrote: 
>>>>>>
>>>>>> I'm not sure that Reactor (Node.js) should be used with Actors. It 
>>>>>> seems that it's a different approaches for solving the same problem - 
>>>>>> concurrency.
>>>>>>
>>>>>>  If JS would have ability to spawn tons of cheap processes - then we 
>>>>>> just don't need such limitation as Node.js async API.
>>>>>>
>>>>>>  So, it seems it's not just a question of some sort of lib for 
>>>>>> node.js - but more like a completely different API on top of Node.js (or 
>>>>>> instead of Node.js).
>>>>>>
>>>>>   -- 
>>>> -- 
>>>> Job Board: http://jobs.nodejs.org/
>>>> Posting guidelines: https://github.com/joyent/**node/wiki/Mailing-List-
>>>> **Posting-Guidelines<https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines>
>>>> You received this message because you are subscribed to the Google
>>>> Groups "nodejs" group.
>>>> To post to this group, send email to [email protected]
>>>>
>>>> To unsubscribe from this group, send email to
>>>> nodejs+un...@**googlegroups.com
>>>>
>>>> For more options, visit this group at
>>>> http://groups.google.com/**group/nodejs?hl=en?hl=en<http://groups.google.com/group/nodejs?hl=en?hl=en>
>>>>  
>>>> --- 
>>>> You received this message because you are subscribed to a topic in the 
>>>> Google Groups "nodejs" group.
>>>> To unsubscribe from this topic, visit https://groups.google.com/d/**
>>>> topic/nodejs/iHSkdmGaRnk/**unsubscribe<https://groups.google.com/d/topic/nodejs/iHSkdmGaRnk/unsubscribe>
>>>> .
>>>>  To unsubscribe from this group and all its topics, send an email to 
>>>> nodejs+un...@**googlegroups.com.
>>>>
>>>> For more options, visit 
>>>> https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
>>>> .
>>>>
>>>>
>>>>  -- 
>>>> -- 
>>>> Job Board: http://jobs.nodejs.org/
>>>> Posting guidelines: https://github.com/joyent/**node/wiki/Mailing-List-
>>>> **Posting-Guidelines<https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines>
>>>> You received this message because you are subscribed to the Google
>>>> Groups "nodejs" group.
>>>> To post to this group, send email to [email protected]
>>>>
>>>> To unsubscribe from this group, send email to
>>>> nodejs+un...@**googlegroups.com
>>>>
>>>> For more options, visit this group at
>>>> http://groups.google.com/**group/nodejs?hl=en?hl=en<http://groups.google.com/group/nodejs?hl=en?hl=en>
>>>>  
>>>> --- 
>>>> You received this message because you are subscribed to the Google 
>>>> Groups "nodejs" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send 
>>>> an email to nodejs+un...@**googlegroups.com.
>>>>
>>>> For more options, visit 
>>>> https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
>>>> .
>>>>
>>>
>>>  -- 
>> -- 
>> Job Board: http://jobs.nodejs.org/
>> Posting guidelines: 
>> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
>> You received this message because you are subscribed to the Google
>> Groups "nodejs" group.
>> To post to this group, send email to [email protected]<javascript:>
>> To unsubscribe from this group, send email to
>> [email protected] <javascript:>
>> For more options, visit this group at
>> http://groups.google.com/group/nodejs?hl=en?hl=en
>>  
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "nodejs" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to [email protected] <javascript:>.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>

-- 
-- 
Job Board: http://jobs.nodejs.org/
Posting guidelines: 
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

--- 
You received this message because you are subscribed to the Google Groups 
"nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to