<commit_before># Zetta Runtime Code Reference

File list:

```
zetta-runtime
├── app_resource.js
├── bootstrapper.js
├── cloud.js
├── cloud_client.js
├── device.js
├── fog_agent.js
├── fog_app_loader.js
├── fog_runtime.js
├── http_scout.js
├── logger.js
├── machine_config.js
├── observable_rx_wrap.js
├── pubsub_resource.js
├── pubsub_service.js
├── registration_resource.js
├── registry.js
├── scientist.js
├── web_socket.js
├── zetta.js
└── zetta_runtime.js
```

## app_resource.js

Run as part of `FogAppLoader#load` (`fog_app_loader.js`), `AppResource.create` builds dynamic resource classes based on exposed devices' `MachineConfig` instances.  AppResource pieces together the appropriate Siren representations for the device, setting HTTP routes, and handling state transitions via actions.

## bootstrapper.js

The bootstrapper is what is called by the CLI when executing `zetta run`.  Its responsibility is to look for a locally deployed app in an `app` directory, discover and load a config file (how we were passing in NPM scouts/devices in the past), load the app from the previously discovered directory, and initiate any connections to peers.

Much of this will have to change, as we're evolving the app concept and introducing a server concept.  Some of this will be merged with the functionality of `cloud.js`.


## cloud.js

`ZettaCloud` is the entry point to the Zeta server.  It manages API client connections, peer connections, client event stream subscriptions, and collector subscriptions.

Sample usage:

```
var cloud = new ZettaCloud();
cloud.setup();
cloud.listen(3000);
```

This file represents a lot of functionality.  This is where the SPDY connection management lives.  This file contains the server code that accepts connections from Zetta instances and sets up the peer association via SPDY.  API requests are proxied to appropriate peers.  Subscription requests to this cloud instance create subscription requests to relevant peers.  Event streams are then routed to subscribed API clients and data collectors.

## cloud_client.js

When using `zetta run` via the CLI, `CloudClient` runs a SPDY server and opens a WebSocket connection for a peering request.  When run by `Cloud#setup`, the `CloudClient` doesn't appear to be doing much, except setting a correlation ID, which may not be needed.  Consider altering that functionality.

## device.js

Appears to not be in use.

## fog_agent.js
<commit_msg>Removing reference to device.js in code_reference.md<commit_after># Zetta Runtime Code Reference

File list:

```
zetta-runtime
├── app_resource.js
├── bootstrapper.js
├── cloud.js
├── cloud_client.js
├── fog_agent.js
├── fog_app_loader.js
├── fog_runtime.js
├── http_scout.js
├── logger.js
├── machine_config.js
├── observable_rx_wrap.js
├── pubsub_resource.js
├── pubsub_service.js
├── registration_resource.js
├── registry.js
├── scientist.js
├── web_socket.js
├── zetta.js
└── zetta_runtime.js
```

## app_resource.js

Run as part of `FogAppLoader#load` (`fog_app_loader.js`), `AppResource.create` builds dynamic resource classes based on exposed devices' `MachineConfig` instances.  AppResource pieces together the appropriate Siren representations for the device, setting HTTP routes, and handling state transitions via actions.

## bootstrapper.js

The bootstrapper is what is called by the CLI when executing `zetta run`.  Its responsibility is to look for a locally deployed app in an `app` directory, discover and load a config file (how we were passing in NPM scouts/devices in the past), load the app from the previously discovered directory, and initiate any connections to peers.

Much of this will have to change, as we're evolving the app concept and introducing a server concept.  Some of this will be merged with the functionality of `cloud.js`.


## cloud.js

`ZettaCloud` is the entry point to the Zeta server.  It manages API client connections, peer connections, client event stream subscriptions, and collector subscriptions.

Sample usage:

```
var cloud = new ZettaCloud();
cloud.setup();
cloud.listen(3000);
```

This file represents a lot of functionality.  This is where the SPDY connection management lives.  This file contains the server code that accepts connections from Zetta instances and sets up the peer association via SPDY.  API requests are proxied to appropriate peers.  Subscription requests to this cloud instance create subscription requests to relevant peers.  Event streams are then routed to subscribed API clients and data collectors.

## cloud_client.js

When using `zetta run` via the CLI, `CloudClient` runs a SPDY server and opens a WebSocket connection for a peering request.  When run by `Cloud#setup`, the `CloudClient` doesn't appear to be doing much, except setting a correlation ID, which may not be needed.  Consider altering that functionality.

## fog_agent.js

{'fraction_non_alphanumeric': 0.08027995059695348, 'fraction_numerical': 0.0016467682173734047, 'mean_word_length': 4.875453446191052, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '7183291', 'n_tokens_mistral': 1351, 'n_tokens_neox': 1339, 'n_words': 648}