resurect router #76

Closed
gjohnson opened this Issue Dec 23, 2012 · 6 comments

Comments

Projects
None yet
2 participants
@gjohnson
Collaborator

gjohnson commented Dec 23, 2012

I could use the router again, mainly to keep our setup not rely on dns for every specific endpoint. On my winter break now so would like to take the time to re-invent it again. Let me know if your super against it, but the differences from the last one would be mainly hiding the delimiter from users. Need to look at our past conversations for anything else, but that's what stands out.

@tj

This comment has been minimized.

Show comment Hide comment
@tj

tj Dec 28, 2012

Owner

at least from what we've been doing I didn't find it necessary, I guess mostly because you can do it with a few lines of code

Owner

tj commented Dec 28, 2012

at least from what we've been doing I didn't find it necessary, I guess mostly because you can do it with a few lines of code

@gjohnson

This comment has been minimized.

Show comment Hide comment
@gjohnson

gjohnson Dec 28, 2012

Collaborator

Hmm... are you using just a raw axon.Socket as a the router? Also, how are you routing envelopes to the endpoint without mapping identities via a greeting?

Collaborator

gjohnson commented Dec 28, 2012

Hmm... are you using just a raw axon.Socket as a the router? Also, how are you routing envelopes to the endpoint without mapping identities via a greeting?

@tj

This comment has been minimized.

Show comment Hide comment
@tj

tj Dec 28, 2012

Owner

oh sorry yeah we're just relaying PUB so I guess that doesn't count, what we're doing for req/rep is autonomous service lookup/maintenance but that was a reasonable amount on top of axon and doesn't localize the connections like you mentioned, im down for looking into it again

Owner

tj commented Dec 28, 2012

oh sorry yeah we're just relaying PUB so I guess that doesn't count, what we're doing for req/rep is autonomous service lookup/maintenance but that was a reasonable amount on top of axon and doesn't localize the connections like you mentioned, im down for looking into it again

@gjohnson

This comment has been minimized.

Show comment Hide comment
@gjohnson

gjohnson Dec 28, 2012

Collaborator

sweet... sorry for the noise this comment will cause, just referencing these to make sure I cover all the bases.

Original impl was in #26
Deal breaker was #33

Random shit to remember: #65, #46, #44, #35, #20.

Collaborator

gjohnson commented Dec 28, 2012

sweet... sorry for the noise this comment will cause, just referencing these to make sure I cover all the bases.

Original impl was in #26
Deal breaker was #33

Random shit to remember: #65, #46, #44, #35, #20.

@tj

This comment has been minimized.

Show comment Hide comment
@tj

tj Dec 28, 2012

Owner

haha no worries it didnt seem to create new notifications for them, I've got about 100 to go through anyway no big deal

Owner

tj commented Dec 28, 2012

haha no worries it didnt seem to create new notifications for them, I've got about 100 to go through anyway no big deal

@gjohnson

This comment has been minimized.

Show comment Hide comment
@gjohnson

gjohnson Dec 31, 2012

Collaborator

I've got this basically working again, however there is a little ambiguity internally between "identity" and "message id's", the latter of the two being the callback id for req->rep. It's not a big deal for the internal code but it does make the user land a little confusing, wanted to see your take on it....

For example:

// rep client

rep.set('identity', 'the-worker');

rep.on('message', function(msg, reply){
  assert(msg == 'hi');
  reply('bye');
});

rep.connect(4444);

// router server

router.on('message', function(from, to, msg, id){
  console.log('%s sent msg: %s', from, msg);
  // proxy along...
  router.send(to, msg, id);  
});

router.bind(4444);

// req client

req.send('the-worker', 'hi', function(msg){
  assert(msg == 'bye');
});

req.connect(4444);

The "id" being the kinda awkward part, since we keep that hidden away from the users when its just plain req->rep. In reality mostly everyone will use router as a proxy and just do something like:

router.on('message', function(from, to){
  var msg = [].slice.call(arguments, 1);
  router.send(msg);
});

Sooooo yeah.... maybe it's not as bad as I think it is, but any ideas on how to make it user friendly?

Collaborator

gjohnson commented Dec 31, 2012

I've got this basically working again, however there is a little ambiguity internally between "identity" and "message id's", the latter of the two being the callback id for req->rep. It's not a big deal for the internal code but it does make the user land a little confusing, wanted to see your take on it....

For example:

// rep client

rep.set('identity', 'the-worker');

rep.on('message', function(msg, reply){
  assert(msg == 'hi');
  reply('bye');
});

rep.connect(4444);

// router server

router.on('message', function(from, to, msg, id){
  console.log('%s sent msg: %s', from, msg);
  // proxy along...
  router.send(to, msg, id);  
});

router.bind(4444);

// req client

req.send('the-worker', 'hi', function(msg){
  assert(msg == 'bye');
});

req.connect(4444);

The "id" being the kinda awkward part, since we keep that hidden away from the users when its just plain req->rep. In reality mostly everyone will use router as a proxy and just do something like:

router.on('message', function(from, to){
  var msg = [].slice.call(arguments, 1);
  router.send(msg);
});

Sooooo yeah.... maybe it's not as bad as I think it is, but any ideas on how to make it user friendly?

@gjohnson gjohnson closed this Oct 30, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment