Skip to content

add scheduling patterns, queue, semantic sugar #18

@shababo

Description

@shababo

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_start with `@ether_run_on_topic(topic = 'run_trial')

ether_get

  • could have ether.collect() and ether.collect_all() where the former gets what's ready and the latter blocks until everything is done
  • wait_for_sync should send out the sync topic message if sync wasn't called already
    The difference between get and sync is 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 like ether.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 of ether_pub and there is no topic variable, then have ether_from(source='class.methodname') which receives emits
    • similarly, have ether_listen() with no topic and ether_to which sends to listen

Metadata

Metadata

Assignees

Labels

No labels
No labels

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions