-
Notifications
You must be signed in to change notification settings - Fork 47
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
API consistency for auto:false & ability to observe/consume on same port #34
base: master
Are you sure you want to change the base?
Conversation
…:true (for cases when auto:false to work the same way)
…require('seneca')
@pdspicer this is a legitimate feature. I'm just about to release 1.0.0 and will review again once that is out. |
Will keep an eye out for review, thanks |
@pdspicer I think that is the last of the big changes in. I did try to merge but I'm short on time so didn't manage to get it resolved. If you can resolve the conflict we can look into this more. As Richard said, looks like a valid use case and one we should look at soon after release. |
# Conflicts: # README.md # mesh.js
Managed to get it merged in, changes should only affect behavior of the add_client() function |
Awesome! @rjrodger Have a quick eye over. LGTM. I'll merge in tomorrow and publish if all ok. This should make mapping out meshes nicer. |
@pdspicer Just reviewing this again - you are able to use multiple listens, like so: seneca.use('mesh', {
listen: [
{pin: 'get:content'}, // model:consume; the default
{pin: 'clear:cache', model:'observe'}
]
}) Does this achieve what you need? |
If I set up seneca-mesh as follows with a static port and auto:false
I lose the ability to specify a model per pin. I would like to be able to specify my pins as follows:
kind of like you can if you use auto: true.
If I am running on multiple machines inside a network with strict firewall restrictions, being able to specify explicit ports is a valuable feature. But the current implementation seems to allow this at the expense of the flexibility to specify different models on a single port.
Since the models are only actually utilized by the balance-client, it seems as though allowing both observe and consume on a single port should be possible. This improves the consistency of the API for listen between auto:true and auto:false, and increases the flexibility of the auto:false listen() calls. You can also do interesting things like change the default model to observe, if you set the options as follows:
then any pins defined as strings will default to observe unless otherwise specified