Very cool! Could be a kind of open-source, text-based (eg recipes are .md with instructions) version of KeyboardMaestro!
I'd love to see such an "open automation" format (could even be more general than pure software, could also automate your IoT or whatever, through extensions)
eg you could have a file "Type my bank login password" for bank websites which doesn't let you use keyboard input but force you to click on stuff, like a self-documented script using .md with code
# Type my bank login password
## Trigger
```trigger:hotkey
key: cmd+l
filter: frontmost-app=Chrome and chrome.tab.url=~mybank.com/login
```
## Deps
```ensure-deps
shell-runner>=1.*
screen-ocr>=1.*
python-runner>=1.*
```
Ensure that my system has the proper extensions for the framework, to run all tasks
## What it does
This automation lets me input my password in a "click-only" input for my lousy bank UI
```run:shell /bin/sh:capture-output=password
echo $(op --vault personal --site mybank)
```
(the above runs the shell script and captures the output as a "password" variable I can use in other scripts below)
```run:screen-ocr:capture-output=ocr-result
window:chrome
```
...go on scripting using typescript/python to locate the numbers in the ocr-result
Co-founder here! No current plans to support SQLite. We picked Postgres because of its huge ecosystem--you can use DBOS with any PostgreSQL-compatible database (Supabase, Neon, Aurora, Cockroach...) and with any Postgres extension (here's an example app using pgvector: https://github.com/dbos-inc/dbos-demo-apps/tree/main/python/...)
(After a quick look at the code) Is this due to concurrency (writes)? It looks like this architecture supports multiple executors, and I would imagine you require transactional guards to ensure consistency. I really like this interface btw, the complexity is hidden very well and from reading your docs it remains accessible if you need to dig deeper than a decorator.
And how the heck are you maintaining Typescript and Python copies? lol
Thanks for your kind words! We're focusing on Postgres because an important scenario for durable execution is serverless computing, which won't work with an embedded database.
I am sure you are aware of this, but if not: there are some emerging technologies around embedded database scale-out using CRDT and other replication protocols that would support various “serverless” (as in decentralized) topologies. PGLite, sqlite-cr, libSQL et al. I am informally looking at for serverless executor agents that do not need to coalesce around a central database instance (“server-full”).
I am sure you tested something like this, I would guess that classic/CDC replication lag would throw a big wrench into an attempt to orchestrate disconnected remote executors, I am hoping that in a peer to peer topology this new tech will have low enough sync latencies to be useful.
Best of luck with DBOS! You have an amazing team.
No, but you’re the first person I’ve ever seen mention TileDB in the wild. I applied there a few years ago; didn’t go anywhere, but I’ve been keeping an eye on them ever since, because I think it’s an interesting idea.
Extremely easy in the black market if you have the money. This is the cuban eBay: http://www.revolico.com. It is sometimes cheaper than in USA in absolute prices, but of course, this is a lot of money for most normal people.
Has anyone been able to combine this with python? I have some python ML code that would be difficult to port to js and it would be nice to be able to pack everything together.
https://github.com/elyase/screenium