Files and processes

Package names on this page are preview naming and may change before launch.

Files

Reading and writing files will be part of the standard library on targets with a file system: desktop and server programs, and containers. Small networked boards will have optional storage of their own; Microcontroller boards describes what each board will provide.

Scoped to the folders you grant

Code will work with files through a handle to a folder that your program has been granted, never through the whole file system.

• The operations will read, write and list files, and read their metadata, inside that folder and the folders below it.
• A path that would leave the folder, through .. or a link, will be refused. The check will work from the folder's handle, not from the text of the path, so a link or a rename made while your program runs cannot get around it.
• Using files will be the storage effect. A function that touches a file will say so through every function that calls it; see Effects and capabilities.

Bounded reads

A read will fill bounded text, a bounded list or a byte array, so it never takes more memory than the capacity you chose. Data that does not fit will be reported as an error, never dropped silently. Text and collections describes the capacities.

What folder scoping will not be

Scoping will keep your own program from reaching files it should not touch. It will not be a sandbox for a hostile program: run code you do not trust in isolation, for example on a remote worker (see execution/remote below).

On the smallest boards there will be no file system, and file operations will fail when you build, not on the device.

Running your own programs

AEL will run programs you already have, and shell commands, as typed tools: your code will send typed arguments and receive a typed result. This will come from optional official packages, so a program that does not use it carries none of it. Calling your existing programs shows the same packages from an agent's side.

You will add one like any other package, with ael pack add (command names may change before launch):

ael pack add execution/process

These packages, like every AEL package, will be written in AEL and ship as compiled, verified AEL, with no bundled native code and no install scripts.

Arguments will stay data

• Arguments will be a list of separate values, never joined into one command line. A file name with spaces, quotes or a leading hyphen will stay one argument.
• Only the shell package will interpret shell syntax, and only in the command text you give it.
• The working directory and the environment will be explicit: a program will receive the environment values you list, and secrets will be passed by reference, never written into your source or logs.

Limits on every run

• Every run will have a finite deadline.
• Standard input, output and error will be bounded byte streams. When output passes its limit, the run's result will say so, with the number of bytes produced and kept where they are known.
• CPU, memory, process-count and temporary-storage limits will be settable per run. Where a platform cannot enforce a limit you asked for, the run will be refused rather than started without it.

Outcomes

The result will keep these apart, so your code can react to each:

• the program exited normally;
• it exited with a failure status, or the operating system stopped it;
• it could not be started;
• it ran past its deadline;
• it was cancelled;
• it reached a resource limit;
• its output could not be read as the type you expected;
• the capability is not available on this target.

An exit status of zero will not skip your output checks: a typed result will be accepted only after it has been decoded and checked.

Cancellation and retries

On cancellation, AEL will stop the program from starting new child processes, ask it to stop, stop it by force after a grace period, and clean up the whole process tree. A run whose result is lost, for example with a remote worker that stops answering, will be reported as uncertain. It will not be run again automatically: whether a command may be repeated will be for your code to decide.

Runtimes are yours

AEL will not install Python, a JavaScript runtime, Java or .NET for you. You will provide the runtime your programs need, on the same machine or on a remote worker. A minimal container image will hold no shell or other runtime unless you put one in it, and a microcontroller board will run no processes: use a remote worker or a gateway from there.

A program you start that calls a model on its own will be outside AEL's accounting: its token usage will be reported as not observed, never as zero.

Not yet described

The names of the file and process operations, and of the permissions they need, will be published when the library is final.