Hi Guys (nameko + newbie = namekbie)
I've been messing with nameko for a very short while and I've thought it
may be a great choice for what I want to do but I'm struggling with the
best approach to perform something.
I currently have a class that opens a long running chunked http request and
as chunks come down the line I want to emit an event ala pub/sub.
Now I've managed to do this with a vanilla python class and creating a
nameko event dispatcher in a stand alone mode(like in one of the examples).
This does a great job of spitting out events as data comes down the long
running http request.
Ideally.. (here is the rub) I would like that event streamer to respond to
rpc calls much like a service would. That way others in the network can ask
the streamer to subscribe to additional items, in turn it would close its
long running http request and then re-open one with the additional items
and start dispatching additional events. I could also ask it to shutdown
etc.
Previously in pre-nameko I had basically rolled my own rpc server and
greenlet forked the long running process and wired them up that way but I
want to use nameko and cleanly.
I can only ever see 1 instance of this service running.. I'm struggling
with the lifecycle of nameko.. should I create an extension.. should I
create a custom container.. boing.. head hurts.
any ideas?
Ok.. re-reading Key Concepts — nameko 2.11.0 documentation
and moving
towards Writing Extensions — nameko 2.11.0 documentation
it looks like creating my own extension and entrypoint would be a good
place to start. The entrypoint can fire the service method when new data
arrives from the polling http.
I'll have to take a closer look and see if the entrypoints underlying is
share across multiple services.. I don't want 2 long polling http's setup.
saturday talking to self because i didnt RTM, over and out 
···
On Saturday, 10 September 2016 10:17:24 UTC+1, Stephen Foster wrote:
Hi Guys (nameko + newbie = namekbie)
I've been messing with nameko for a very short while and I've thought it
may be a great choice for what I want to do but I'm struggling with the
best approach to perform something.
I currently have a class that opens a long running chunked http request
and as chunks come down the line I want to emit an event ala pub/sub.
Now I've managed to do this with a vanilla python class and creating a
nameko event dispatcher in a stand alone mode(like in one of the examples).
This does a great job of spitting out events as data comes down the long
running http request.
Ideally.. (here is the rub) I would like that event streamer to respond
to rpc calls much like a service would. That way others in the network can
ask the streamer to subscribe to additional items, in turn it would close
its long running http request and then re-open one with the additional
items and start dispatching additional events. I could also ask it to
shutdown etc.
Previously in pre-nameko I had basically rolled my own rpc server and
greenlet forked the long running process and wired them up that way but I
want to use nameko and cleanly.
I can only ever see 1 instance of this service running.. I'm struggling
with the lifecycle of nameko.. should I create an extension.. should I
create a custom container.. boing.. head hurts.
any ideas?
Hi Stephen,
Ok.. re-reading Key Concepts — nameko 2.11.0 documentation
and moving towards
Writing Extensions — nameko 2.11.0 documentation
it looks like creating my own extension and entrypoint would be a good
place to start. The entrypoint can fire the service method when new data
arrives from the polling http.
Yep, this is exactly the pattern you want.
I'll have to take a closer look and see if the entrypoints underlying is
share across multiple services.. I don't want 2 long polling http's setup.
The WebServer class in nameko.web.server is a SharedExtension, meaning that
if multiple entrypoints declare it they share the same instance. The whole
of nameko.web is pretty small and should give you a decent idea where to
start.
saturday talking to self because i didnt RTM, over and out
Matt.
···
On Saturday, September 10, 2016 at 12:15:12 PM UTC+1, Stephen Foster wrote:
On Saturday, 10 September 2016 10:17:24 UTC+1, Stephen Foster wrote:
Hi Guys (nameko + newbie = namekbie)
I've been messing with nameko for a very short while and I've thought it
may be a great choice for what I want to do but I'm struggling with the
best approach to perform something.
I currently have a class that opens a long running chunked http request
and as chunks come down the line I want to emit an event ala pub/sub.
Now I've managed to do this with a vanilla python class and creating a
nameko event dispatcher in a stand alone mode(like in one of the examples).
This does a great job of spitting out events as data comes down the long
running http request.
Ideally.. (here is the rub) I would like that event streamer to respond
to rpc calls much like a service would. That way others in the network can
ask the streamer to subscribe to additional items, in turn it would close
its long running http request and then re-open one with the additional
items and start dispatching additional events. I could also ask it to
shutdown etc.
Previously in pre-nameko I had basically rolled my own rpc server and
greenlet forked the long running process and wired them up that way but I
want to use nameko and cleanly.
I can only ever see 1 instance of this service running.. I'm struggling
with the lifecycle of nameko.. should I create an extension.. should I
create a custom container.. boing.. head hurts.
any ideas?
Hey Matt thanks for the response.
I actually ended up browsing the webserver and saw the shared extension code and such which put me on the path. Good to hear my approach was confirmed by you.
I created a shared extension for the polling and entry point with decorator etc. Then a simple streaming service that fired off events and responded to rpcs, delegating to the shared extension for subscriptions yada yada.
Short version is I read the docs again, scanned some examples and code and built something discovering in the process that nameko was doing loads of the hard work for me and it's extremely simple once you get your head around it.
Thanks for the tools and support
Cheers Stephen.