[erlang-questions] object vs. actor (Re: Massive Numbers of Actors vs. Massive Numbers of Objects vs. ????)

[Miles Fidelman]

Garrett Smith wrote:

> Just my two cents, but I'd take the energy spent here trying to define
> "object" and "actor" and start thinking about how you're going to
> build the system:

well duh.. :-)

questions/discussion here are about trying to bounce concepts off 
people, and try to uncover technologies that are not all that visible

>
> - How do you store the data? (MySQL, MongoDB, Riak, Mnesia, multiple
> stores -- the list of options is *huge* and )

would sort of be nice to store data as simply a large cloud of Erlang 
processes - hence inquiries and discussion here

but, at least in the short term, most likely is CouchDB for early 
versions (has most of the characteristics I'm looking for), though some 
possibility of using eXist (XML document store, with APP/Atom interfaces 
already available)

probably leverage an erlang web framework (Yaws, Mochiweb, Nitrogen)
>
> - What are you going to write your "business logic" in (Java, Python,
> Erlang, all of the above -- I assume your questions here are related
> to how suitable Erlang is for the job -- I'd say pretty good based on
> what you're looking for)

embedded in documents, i.e., Javascript embedded in HTML/XML; possibly 
embedded erlang as well (I'm pretty sure Couch supports embedded erlang 
scripts)

> - How are you going to communicate between nodes / servers / programs?

protocol based - XMPP or Atom/APP, with support for message based 
protocols as well (SMTP, NNTP, possibly IMAP for access)

>
> Looking for a conceptual model is probably not a total waste of time,
> but at some point, you'll have to evaluate your options on those three
> points based on technical merit.
I've generally found it useful as a way to organize thinking.

> As far as the "actor" model and massive concurrency, as as been said,
> Erlang will give you options that other language environments won't.

Absolulutely, but it doesn't quite go as far as I'd like.  Erlang is 
great for massive concurrency, not so great if you want huge numbers of 
processes to persist, perhaps permanently.

Our application will be distributing HTML+Javascript documents by email 
- message like, but also object-like and actor like when live in a 
client or browser.  The question is how to maintain the actor-like 
behavior when filing away large numbers of emails.

It would be interesting to simply store each message as an erlang 
thread, accessed through message passing.  But that doesn't scale with 
current technology.  The short term answer is clearly to use a database 
of some sort, but a longer solution would be to find ways to support 
large numbers of hibernating processes.
> You can even call them "objects" and the VM will work just the same :)
>
I could call them that, but erlang does NOT support object-oriented 
programming in the sense of inheritance and so forth.

Miles


-- 
In theory, there is no difference between theory and practice.
In practice, there is.   .... Yogi Berra