andrewvc / dripdrop Goto Github PK

After making rspec run on my 1.9.2 ruby I've realized some spec are broken.

Some of them are fixed using DripDrop::Node.error_handler instead of DripDrop::Node#error_handler. Patch is here: oruen/dripdrop@717e8870a574c1114dba5945e5d5c26f78a416a0

Others looks a little bit strange:

[oruen@192 dripdrop (master %=)]$ rspec spec/node/zmq_xrepxreq_spec.rb

zmq xreq/xrep
  basic sending and receiving
Expected message in at least 3 parts, got ["\x00\v\x97s^\x18 I\xCD\x81\xF8t\xBFd]\xA0a", "{\"name\":\"test-0\",\"head\":{\"message_class\":\"DripDrop::Message\",\"_dd/xctr\":1},\"body\":null}"]/Users/oruen/apps/my/dripdrop/lib/dripdrop/handlers/zeromq.rb:200:in `on_readable' 

I'm using Ruby 1.9.2 and zmq from head at zeromq/zeromq2@29e0e7dbadfcd0bab70feee119bd7c5e623b38d4

Keeping track of sockets in complex apps with dripdrop sucks. Maybe some sort of routing a la Rails routes would help? maybe it'd be terrible. A worthwhile experiment.

sockets should be destroyable.

Hello, i was wondering if there is a way of answer a rq from a separate nodelet. I'm trying to replicate the mongrel2 zmq behaviour using multiple "workers"

Thin's a great server, but it doesn't work with jruby. Boo. perhaps evma-httpserver?

dripdrop needs logging damnit, and debug messages letting you trace messages during dev.

websockets are the only stateful protocol dripdrop currently supports, and they're awkward, fix this.

I'm unhappy with nodelet class interface as it stands now, I'm thinking of ways to fix it. Here's some ideas, I'd like some feedback.

As it stands now, you declare your nodelet class, and can optionally include a #configure method, which gets called on initialization. This interacts awkwardly when combined with Node#nodelet do; #block stuff; end. Proposed new interface:

class MyNodelet < DripDrop::Node::Nodelet
def pre_action
end
def action
end
def post_action
end
end

given this new system, when you call say nodelet :mynodelet, MyNLetClass {|nlet| ... }

what would happen is:

1. The nodelet gets initialized
2. Your block gets run in the context of the nodelet
3. pre_action gets called
4. action gets called.
5. post_action gets called.

All of the pre/post/action methods would be optional.

This all dovetails with the new Node#run_list setting quite well, as having a standard #action method means you don't manually have to kick-off your nodelets later.

Hi very interesting. Would you consider dropping use of Thread in node, or at least making it optional some require+include. Alternatives are, I think, reactor pattern, or observer pattern. Observer pattern is my interest. Not sure yet how it would best work, but it would be neater and make the asynchronous behavior explicit, without making it tricky (if properly constrained).

Open to such an approach?

DripDrop needs a routing layer. Juggling addresses is way too much a PITA. Let's see if I can hack this out tonight...

Things it should do:

• Allow ZMQ sockets to bind to multiple addresses
• Auto-detect when a connection makes no sense (I.E. sending a ZMQ Pub message to a WebSocket)
• Make delicious waffles.

It should look something like...
route :chat_ws, :websocket, 'ws://127.0.0.1:1234'
route :chat_in_zsub, :zmq_subscribe, :bind, 'tcp://127.0.0.1:12345'

So, it should pretty much just take a label, followed by the normal arguments used for constructing said socket. Then, it should magically make the socket. You'll be able to use the socket later by calling it by name.

So, given the routes above you could do:

chat_ws.on_recv {...}

Note, that including the abbreviated socket type in the route name is merely recommended, not required, but it's probably a good idea for sanity.

I dont see a way i can publish within several nodelets, is this possible?

Hey guys, I'd like to fix any weird inconsistencies in naming in the API prior to our next gem release in a couple of days. I already pushed one change (renamed websocket to websocket_server) but would like to know if you guys see any other oddities.

One big change I'm thinking of is renaming :on_recv to :on_receive (the old method would work, but be deprecated and print a warning to $stderr).

My reasoning is we should either have on_recv and send_msg, or on_receive and send_message. I'm favoring long names because other parts of the lib tend to use long names as well.

Thoughts?