-
Notifications
You must be signed in to change notification settings - Fork 4
Roadmap
AP Ljungquist edited this page Nov 5, 2024
·
13 revisions
This is a rough sketch of what I want to do. The intention is that it will:
- Help users understand what to expect and suggest changes
- Help would-be contributors identify tasks. Note that other improvements are welcome as well if they fit the larger goals of the project.
Notes:
- Depending on the rendered requirement (solid) and prioritization (dashes) lines may or may not be distinguishable.
- The chart looks better in programs where the elk rendered is supported.
flowchart TB
%%{init: {"flowchart": {"defaultRenderer": "elk"}} }%%
style done stroke: DodgerBlue
style started stroke: GoldenRod
style prioritized stroke: FireBrick
%% Prerequisites are not always hard, oftentimes it just means that it is a sensible way
%% to arrange activities where one facilitates the next.
prioritized-- ( prerequisite ) -->started
%% If the prerequisite will be done, it should be done before
prioritized-- order ( - only prerequisite) --> done
%% This is an even weaker constraint; there is no real benefit from doing one before the
%% other but to build a tall DAG is easier to view than a wide DAG and indicating the
%% order in which I would undertake activities makes is easier to see how far away they
%% are.
%% Expressing these constraints wherever I have an opinion would not be helpful
%% with the current tools and they are added sparsely in order to connect
%% would-be components.
other-. prio ( ritization ) .-> started
internal[activity or artifact]
external(external event)
objective([objective])
flowchart TB
%%{init: {"flowchart": {"defaultRenderer": "elk"}} }%%
15[Add reverse proxy example]
style 15 stroke: DodgerBlue
16[Use float-abi=hard on armv7hf]
style 16 stroke: GoldenRod
18[Add related projects section]
style 18 stroke: GoldenRod
22[Add metadata broker wrapper and example]
style 22 stroke: DodgerBlue
33[Add vapix bindings and example]
style 33 stroke: DodgerBlue
46[Add `device-manager` bin and lib crate]
style 46 stroke: DodgerBlue
%% One thing that is difficult when starting a new project is establishing an
%% architecture that will allow the project to continue growing. Currently the
%% example apps are mostly small and contrived and building anything on top of
%% them is likely to result in a big bowl of spaghetti.
52[Architecture example]
style 52 stroke: GoldenRod
61[Improve README]
style 61 stroke: DodgerBlue
80[add certificate management and MQTT APIs]
style 80 stroke: GoldenRod
96[Improve mdb]
style 96 stroke: GoldenRod
99[Make builds reproducible in dev-container]
style 99 stroke: DodgerBlue
108[Add edge storage wrapper and example]
style 108 stroke: DodgerBlue
110[Add marker for Message]
style 110 stroke: GoldenRod
%% Unlock parallel work.
%% Reduce merge conflicts.
112[Factor out acap-build wrapper to lib crate]
style 112 stroke: DodgerBlue
114[Warn users that commands may break]
style 114 stroke: DodgerBlue
115[Improve ergonomics for consumer]
style 115 stroke: GoldenRod
116[Improve Error]
style 116 stroke: GoldenRod
117[Don't invalidate Cargo caches]
style 117 stroke: DodgerBlue
%% Checking generated files is clumsy because it depends on having previously made `check_all`.
%% It also seems redundant to build all apps three times in CI counting the host workflow.
118[Streamline CI]
style 118 stroke: DodgerBlue
%% Facilitate relocating the SDK
%% Unlock parallel work.
%% Reduce search space in case of regressions.
119[Enable bypassing acap-build]
style 119 stroke: DodgerBlue
120[Add larod]
style 120 stroke: GoldenRod
%% API regularization.
%% Lower threshold for upstream SDK to adopt and help maintain toolchain.
ab-bin[acap-build binary]
%% If these two can be bypassed then the build tools have no more dependencies that cannot be
%% easily installed with the system package manager.
bypass-ec[Bypass eap-create]
bypass-mp[Bypass manifest2packageconf]
style bypass-mp stroke: GoldenRod
schema-validation[Implement schema validation]
%% Currently the template has a minimal example with the expectation that users
%% prefer to add parts rather than remove them. I don't feel strongly about this
%% assumption and I'm inclined to use a bigger example; at least this would make
%% the repository show up as a Rust repository and since most users find us by
%% browsing GitHub this could be beneficial.
arch-template[Use architecture example in template]
lic-template[Use generated license in template]
%% Avoid dependency on external build system like make
lic-script[generate license from build script]
%% With apt-installable dependencies only on Debian
debian([Rust and apt deps only])
%% With apt-installable dependencies only
ubuntu[Ubuntu compatible]
%% With brew-installable dependencies only
macos[MacOS compatible]
x86[Non-x86-64 host support]
%% Cross compiling with e.g. OpenSSL does not seem to work
ubuntu-xc[Cross compile on Ubuntu]
%% For makefiles to work well, targets must produce a file with a name that is known in advance.
%% This is one of the things that have made integrating acap-build into make and, presumably,
%% other build systems annoying.
%% Another source of friction is that the architecture a.k.a target names are different in an
%% ACAP context compared to a Cargo context.
make[Make compatibility]
%% Ability to install the ACAP SDK without running as root
rootless([sudo-less SDK installation])
style rootless stroke: DodgerBlue
%% Ability to install multiple, concurrent versions of the ACAP SDK on one machine.
concurrent([Concurrent SDK versions])
style concurrent stroke: DodgerBlue
%% Gf the Rust port of build tools prove valuable and get adopted upstream there would be more
%% resources to maintain them instead of fewer resources to keep up with the official tools.
%% I think that demonstrating that a drop-in replacement can be built would help with this.
maintenance([acap-build maintenance])
%% Explore what an API using loading instead of linking would look like.
%% Potential advantages of this include not needing the SDK at build time.
%% A good place to start is the License Key API since it is so small.
loading-zero[Explore libloading]
loading-one[Adopt libloading]
%% CI takes >10 minutes, I expect some basic caching should more than half this.
%% Although I suspect caching the docker builds could prove annoying.
cache[Use caches in CI]
%% The CI often fails because npm could not be installed.
%% This is annoying and erodes trust in CI.
npm[Robust installation of npm in CI]
crate-names[Finalize crate names]
asdk-zero[Publish cargo-acap-sdk 0.y.z]
cab-zero[Publish cargo-acap-build 0.y.z]
rfc3127(trim-paths)
reproducible[Fully reproducible builds]
ab-bin --> 112
maintenance --> ab-bin
118 --> 117
reproducible --> 99
reproducible --> rfc3127
axisos-12(Axis OS 12.0 released)
subgraph asu [acap-ssh-utils]
asu-12[Support for 12.0]
asu-12 -. prio .-> 114
end
subgraph axstorage
axstorage-zero[Publish Edge Storage API 0.y.z]
axstorage-one[Publish Edge Storage API 1.0]
axstorage-storage-type[Explore using custom storage type]
axstorage-safety[Safety audit]
style axstorage-storage-type stroke: GoldenRod
axstorage-storage-type --> 108
axstorage-one --> axstorage-storage-type
axstorage-one --> axstorage-zero
axstorage-one --> axstorage-safety
end
subgraph dm [device-manager]
dm-12[Support for 12.0]
dm-12 --> 46
dm-12 -. prio .-> asu-12
end
subgraph larod
larod-zero[Publish Machine Learning API 0.y.z]
larod-one[Publish Machine Learning API 1.0]
larod-safety[Safety audit]
larod-zero --> 120
larod-one --> larod-zero
larod-one --> larod-safety
end
subgraph mdb
mdb-zero[Publish Message Broker API 0.y.z]
mdb-one[Publish Message Broker API 1.0]
mdb-safety[Safety audit]
mdb-publish[Add publish API]
mdb-stable(libmdb exits beta)
96 --> 22
110 --> 22
115 --> 110
116 --> 115
mdb-one --> 116
mdb-one --> mdb-zero
mdb-one --> mdb-safety
mdb-one --> mdb-publish
mdb-one --> mdb-stable
end
subgraph reverse-proxy
%% When developing a full stack app it is often faster to deploy everything on
%% host but this becomes difficult if the frontend tries to use APIs from the
%% device other than those provided by the app. One solution is proxying unknown
%% requests to a device that can handle them.
reverse-proxy-fallback[Proxy unknown requests on host]
%% Without a signal handler for SIGINT the process exits without unwinding and
%% running any drop implementations. Though programs should be able to recover
%% from a dirty shutdown, having a clean shutdown often makes starting again
%% cheaper.
reverse-proxy-signals[Handle signals]
reverse-proxy-fallback --> 15
reverse-proxy-signals --> 15
end
subgraph vapix
vapix-ws[Event streaming over WebSocket]
style vapix-ws stroke: GoldenRod
80 --> 33
vapix-ws --> 33
end
vapix-ws --> vapix-ws-uer(Interested user)
80 --> 80-user(Interested user)
asu-12 --> axisos-12
dm-12 --> axisos-12
119 --> 99
119 --> 118
%% This is needed to refactor the build system and refactoring the build system
%% is greatly facilitated (enabled?) by being able to test that refactoring does
%% indeed not affect the output.
112 -- order --> 99
119 --> 112
%% If we want to support loading we probably need to do so before 1.0
mdb-one -- order --> loading-one
rootless --> 119
concurrent --> 119
bypass-ec --> 119
bypass-mp -. prio .-> 61
bypass-mp --> 119
schema-validation --> 119
licensekey-one -. prio .-> reverse-proxy-signals
licensekey-one --> crate-names
52 -. prio .-> licensekey-one
arch-template --> 52
lic-template --> lic-script
lic-script -.-> 119
debian --> bypass-ec
debian --> bypass-mp
x86 -. prio .-> debian
make -. prio .-> debian
ubuntu -. prio .-> arch-template
ubuntu -. prio .-> dm-12
ubuntu -. prio .-> axstorage-one
ubuntu -. prio .-> mdb-one
ubuntu -.-> debian
ubuntu --> ubuntu-xc
ubuntu-. prio .-> cache
macos-. prio .-> ubuntu
%% I think having a consistent naming scheme is helpful for users
asdk-zero --> crate-names
cab-zero --> crate-names
axstorage-zero --> crate-names
larod-zero --> crate-names
mdb-zero --> crate-names
loading-one --> loading-zero
debian --> loading-one
npm -. prio .-> lic-template
cache -. prio .-> npm
flowchart TB
%%{init: {"flowchart": {"defaultRenderer": "elk"}} }%%
axstorage[Edge Storage API]
style axstorage stroke: GoldenRod
axevent[Event API]
style axevent stroke: GoldenRod
licensekey[License Key API]
style licensekey stroke: GoldenRod
larod[Machine Learning API]
style larod stroke: GoldenRod
mdb[Message Broker API]
style mdb stroke: FireBrick
axoverlay[Overlay API]
bbox[Bounding Box API]
style bbox stroke: GoldenRod
axparam[Parameter API]
axserial[Serial Port API]
vdo[Video Capture API]
axstorage-. prio .-> mdb
axevent-. prio .-> mdb
larod-. prio .-> mdb
axoverlay-. prio .-> mdb
axparam-. prio .-> mdb
axserial-. prio .-> mdb
vdo-. prio .-> mdb
bbox-. prio .-> mdb
%% Doing things in licensekey makes sense because it is a small API that employs both
%% dynamic and static linking.
mdb --> licensekey
flowchart TB
%%{init: {"flowchart": {"defaultRenderer": "elk"}} }%%
c-ergo[Finalize ergonomic API]
c-unstable[Mark ergo bindings as unstable]
c-draft[Initial implementation]
c-api[Review flex API]
style c-api stroke: FireBrick
c-safety[Review safety]
style c-safety stroke: FireBrick
c-zero[Publish 0.y.z]
c-one[Publish 1.0]
c-ergo --> c-draft
c-safety --> c-draft
c-api --> c-draft
c-zero --> c-draft
c-one --> c-unstable
c-one --> c-zero
c-one --> c-api
c-one --> c-safety
c-one --> loading-one[Explore loading instead of linking]