CouchDB views / capabilities

[Tony Arcieri]

Reia seems like it'd be a great language for CouchDB views.  It would require some sort of sandboxing.  This has been discussed in the past:

http://groups.google.com/group/reia/msg/27653fcc5ca02060

I think this wouldn't be too tricky to implement.  I think Reia could have a "safe mode" which would shut off the following capabilities:

* Erlang interfacing (and by virtue of that, any I/O beyond interprocess I/O, such as accessing the filesystem)
* Generating objects/PIDs except by starting processes or receiving pids as messages (e.g. via a hypothetical Binary#to_pid)
* Reflection (a nice ill-defined ambiguous category of features)
* Metaprogramming? (metalinguistic abstraction is a great way to escape sandboxes)

I think by design the Actor model is great for sandboxing, but that said, I realize this is something easy to get wrong.  Ruby got it terribly wrong with their Perl-inspired "tainting" approach (which they managed to screw up worse than Perl) which remains an almost completely unused "feature" which needlessly detracts from the performance of the language.

That said I think the one thing Perl got right about "tainting" was making it an optional feature.  Perhaps Reia could add a capabilities model, but one which isn't "on" by default?  Most users don't care about sandboxing, but in Reia's case, I think it would be a waste of its Actor model-inspired roots not to optionally offer a capabilities model.

--
Tony Arcieri
medioh.com

[Phil Pirozhkov]

Very nice idea, but I can see some roadblocks

# STDIN/STDOUT performance
People claim that io performance of erlang worth more attention from
Erlang VM
developers. It's not the problem of Reia in any way except for CouchDB
ViewServer
implementation candidate, who's responsible for stdin-read/process/
stdout-write cycle.
Hope this is way better in R13 (still fails to install on both mine
PPC/OS X 10.4 and x86-32/Ubuntu 9),
but haven't found anything concerning io on Changelist except for
Unicode changes.

# Cosmetic.
Reia currently lacks easy property access, such as:
doc.prop
and that can only be done with a Map access syntax:
doc[:prop]

JS:
function(doc) {
if (doc.user_id) {
emit(doc.user_id, null);
}
}

Reia:
def f(doc)
if (doc[:user_id])
emit(doc[:user_id], nil)
end
end

but i'm sure something elegant and powerful can be used instead since
Reia allows:
- to just return, and skip emit() calls;
- skip all this function(doc) junk;
and implement the same just like this:
doc[:user_id] if doc[:user_id]

but i'm sure
doc.user_id if doc.user_id
looks a bit cleaner and easier to type


//
But i'm sure both these won't stop the Brave One from his major night
implementing a ViewServer for CouchDB!
I've taken a look over map/reduce examples, all of them will look much
more compact in Reia (less typing = faster coding)

Cheers, Phil

[Tony Arcieri]

On Mon, May 11, 2009 at 3:25 PM, Phil Pirozhkov <pirj...@gmail.com> wrote:

Very nice idea, but I can see some roadblocks

# STDIN/STDOUT performance
People claim that io performance of erlang worth more attention from
Erlang VM
developers. It's not the problem of Reia in any way except for CouchDB
ViewServer
implementation candidate, who's responsible for stdin-read/process/
stdout-write cycle.
Hope this is way better in R13 (still fails to install on both mine
PPC/OS X 10.4 and x86-32/Ubuntu 9),
but haven't found anything concerning io on Changelist except for
Unicode changes.

Ideally Reia could be executed from the same Erlang node that CouchDB itself is running in, eliminating the need for talking to another process over stdio.

They've experimented with using pure Erlang for views in CouchDB, but so far they haven't done anything production level yet due to the need for sandboxing.

Hopefully, Reia could address this with a capabilities model.
 

# Cosmetic.
Reia currently lacks easy property access, such as:
doc.prop
and that can only be done with a Map access syntax:
doc[:prop]

I would like to address this the same way Ruby does: metaprogramming getter/setter methods e.g. attr_reader/attr_writer/attr_accessor
 
This really seems like the only clean way to do it.

It needs a number of features first though:

* Setter methods
* Metaclasses
* Class bodies
* Metaprogramming

but i'm sure something elegant and powerful can be used instead since
Reia allows:
 - to just return, and skip emit() calls;

I don't have a "return" keyword implemented yet but I have a great idea of how to do so.
 

 - skip all this function(doc) junk;
and implement the same just like this:
doc[:user_id] if doc[:user_id]

but i'm sure
doc.user_id if doc.user_id
looks a bit cleaner and easier to type

The inline if statements are implemented... just need property access.

But i'm sure both these won't stop the Brave One from his major night
implementing a ViewServer for CouchDB!
I've taken a look over map/reduce examples, all of them will look much
more compact in Reia (less typing = faster coding)

I've thought about doing it myself but I haven't taken a look at the pure Erlang views yet.

--
Tony Arcieri
medioh.com