The interface for apps looks much nicer now, see 'main' in zet.tlv.
However there are some open issues:
- It can still be confusing to the computer owner that an app tries to
write to some temporary file that isn't mentioned anywhere.
- File renames can fail if /tmp is on a different volume.
- What happens if an app overrides start_writing()? The computer owner
may think they've audited the caller of start_writing and give it
blanket file permissions. Teliva tunnels through start_writing when
computing the caller. If the app can control what start_writing does,
the app could be performing arbitrary malicious file operations.
Right now things actually seem perfectly secure. Overriding
start_writing has no effect. Our approach for loading .tlv files (in
reverse chronological order, preventing older versions from overriding
newer ones) has the accidentally _great_ property that Teliva apps can
never override system definitions.
So we have a new reason to put standard libraries in a .lua file: if
we need to prevent apps from overriding it.
This feels like something that needs an automated test, both to make
sure I'm running the right experiment and to ensure I don't
accidentally cause a regression in the future. I can totally imagine a
future rewrite that tried a different approach than
reverse-chronological.
Perhaps this is a bad idea. It feels arbitrary, what methods Lua happens
to include in string and table objects without having to go through the
respective modules.
When should code go in the template used by new apps vs the .lua files
distributed with Teliva?
- from a privilege perspective there's no difference
- from a compatibility perspective stuff in .tlv will not get upgraded
with Teliva.
- for me the maintainer, functions in .lua files are easier to upgrade
in a single place.
- for the reader of an app, functions in .lua files will not show up to
be edited. They can still be overloaded, but the current version isn't
as discoverable. Putting something in the app is a slight nudge to
readers that they're encouraged to mess with it.
- Stuff in .lua files can use local functions and so have more internal
complexity. Apps can also hide details within functions, but that'll
make them more likely to run into limitations with Teliva's editing
environment.
I'm not yet sure how to reason about the second point in practice.
- Stuff in .tlv files I don't have to worry about compatibility
guarantees for.
- Stuff in .lua files I _do_ have to worry about compatibility
guarantees for.
Perhaps this means I'm doing things exactly wrong in this commit?
Functions like map/reduce/filter/append seem more timeless, whereas I'm
still just feeling my way around with start_reading and start_writing.
We'll see. For now I'm ruled by the fourth point. Messing with tasks and
the scheduler is much more advanced than anything else in template.tlv;
it seems to make sense to add some friction to modifying them.
Bottomline: Complex sub-systems go in .lua files. Simple, self-contained
definitions go into apps. Both are probably equally burdensome now from
a compatibility perspective.
They may take more or less from it (sieve.tlv in particular takes
nothing since call depth doesn't help at all there), but what they take
is in the right order so that you can compare across apps.
Tasteful apps should only perform side-effects through 'window'
arguments rather than the 'curses' module directly. It's ok however to
read constants like curses.A_NORMAL or curses.stdscr().
There are some limitations, unfortunately. Ncurses wasn't designed with
testability in mind. For example, there's no way to curs_set or
assume_default_colors without the 'curses' module. Oh well.
We also made render dynamic, showing zettels in the first place it
encounters them in depth-first order.
Open question: how to show a collapsed outline view with the data model
I'm experimenting with. Not even clear 'outline' has meaning in the
presence of cross-links. Outliners privilege one view of the network.
Zettelkasten also does so; changing child/sibling relationships is a lot
of work. However, reading between the links it seems to try to provide
an escape hatch for rethinking connections using cross-links. I'm trying
to lean into that -- at the cost of providing outlines. We'll see if
this is a good trade-off.
Conundrum:
I want the app to provide some sample data for people to interact with.
However, I also want them to be able to delete it to make it their own.
BUT I'm not yet convinced the app should allow deletion in general.
Besides, deleting stuff robustly and reliably is a whole other level of
programming.
Solution:
Make people edit the app to clear the initial sample zettels.
This has the "beneficial" side-effect of getting them editing apps on
Teliva.
https://merveilles.town/@akkartik/107742821323590471
What we have so far:
a representation (see 'zettels')
parent/child
next/prev sibling
(todo: misc cross-links)
ability to render zettels in multiple columns based on 'view_settings'
all zettels render with same size
alternate backgrounds between zettels for legibility
skip rendering duplicates (if we ever hit cycles)
a highlighted 'current zettel'
ability to move current zettel
by screen location (arrow keys)
by network structure (h/j/k/l)
Still can't edit zettels or load/save from/to disk.
Kartik K. Agaram