Clean up the registry API

[aflatter]

As per celluloid/floss#14, the registry API is to be refactored. As per a discussion with @tarcieri on IRC, this includes the following changes:

A new API for implementing a registry.

class RegistryAdapter
    def initialize(options = {})
    end

    def get(namespace, key)
    end

    def set(namespace, key, value)
    end

    def keys(namespace)
    end

    def clear(namespace)
    end
end

A registry should be an actor too.

Refactor Global and Directory

Provide a NamespaceProxy to DRY this up:

global = registry[:global] # => DCell::Registry::NamespaceProxy
global[:foo] = :bar

One of the following:

• Provide DCell.global[:foo] and DCell.directory[:bar] (or DCell[:global, :foo])
• Use Node[:bar] for the directory and DCell[:bar] for globals.

Opinions?

[tarcieri]

I think the registries should probably be actors. Now that celluloid/celluloid#287 is landed and the inheritance anomalies have been eliminated, perhaps registries should descend from an abstract base class that includes Celluloid by default.

[spangenberg]

What about a delete method like I did here https://github.com/parcydo/dcell/commit/efdda59ddb90859a88516704f3b861eff7664d30, it's pretty much related to #6

A TTL is one way to solve this but I do it right now different and this requires a delete in the registry.

node = DCell::Node[:foo]

dispatched = false

after(2) do
  unless dispatched
    Logger.warn "Delete node #{node.inspect}"

    node.delete
  end
end

dispatched = node[:bar].baz

[halorgium]

In the floss impl, the registry backends are actors.
I don't think we should have these actors as Cells, but perhaps we can wait for my celluloid/celluloid#291 PR.

[tarcieri]

@halorgium why not?

[halorgium]

@tarcieri dunno, was a thought. the RPC overhead especially for the floss project means double-accounting.

[tarcieri]

"Overhead" was my original motivation for designing the API the way it was. Fuck that. Make everything an actor FTW ;)

[halorgium]

Haha! Good call.
@aflatter would you feel OK spiking out an impl which used actors?
I'm not sure how the bootup process would look like.

[tarcieri]

I should probably expound: lots of cases cropped up where the registry being an actor was advantageous. The most notable was Zookeeper where an actor could keep a local cache which Zookeeper could actively invalidate and replace with new values. Saving a network trip while still receiving push updates in realtime is a huge win

[aflatter]

@tarcieri, @halorgium: I think the overhead is negligible for now. DCell::Registry::Base already is an actor: aflatter@b51d622#L2R2

@Neonlex I don't really like exposing such functionality. The Node#delete method removes a node from the directory, thus making it inaccessible for all other nodes too. DCell should handle node unavailability in a deterministic way, maybe using distributed concensus.

[Asmod4n]

@tarcieri @aflatter @halorgium zeromq(czmq) can soonish be used to handle all registry needs, https://github.com/zeromq/czmq/blob/master/src/zgossip.c#L442 might be of interest.

Have also written a ruby ffi wrapper for czmq, here is a gossip example: https://github.com/Asmod4n/ruby-ffi-czmq/blob/master/examples/gossip.rb

[tarcieri]

Cool!

[niamster]

I've cleaned up a bit the Registry API in pull request #91
Though, as @tarcieri I have doubts whether those should be actors. I noticed a quite noticeable overhead in my stress testing.
Probably a particular implementation should be an actor if registry BE library can't handle asynchronous requests. Mainly DCell does read access so I don't see a good reason to serialize access.

[niamster]

No feedback means everybody satisfied with current registry API?