-
Notifications
You must be signed in to change notification settings - Fork 0
add scheduling patterns, queue, semantic sugar #18
Copy link
Copy link
Open
0 / 20 of 2 issues completedDescription
It's time to implement some more abstraction on top of common messaging and (a)synchronization patterns.
ether_sub abstractions/add ons
handle slow processing
-
@ether_sub(queue_length = 1,...)
handle triggering
-
@ether_run_interval(interval_seconds = 0, ...) -
@ether_run_schedule(times = [list: datetime], ...) -
@ether_run_datawatcher(...): this will link to a standard datastore interface that could be a directory or database - could replace
@ether_startwith `@ether_run_on_topic(topic = 'run_trial')
ether_get
- could have
ether.collect()andether.collect_all()where the former gets what's ready and the latter blocks until everything is done wait_for_syncshould send out the sync topic message ifsyncwasn't called already
The difference betweengetandsyncis that the later is some combination of publish where we know how many subscribers there are... honestly, not 100% clear on this, but we'll figure it out.-
ether.stream(...)sets up something likeether.collect()but it's less about waiting for a discrete set and more about getting a continuous flow of data from somewhere.
more semantic naming for pub/sub decorators
- consider having
ether_emit()instead ofether_puband there is no topic variable, then haveether_from(source='class.methodname')which receives emits- similarly, have
ether_listen()with no topic andether_towhich sends to listen
- similarly, have
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
No labels