search

salmanahmad / dog

The Dog Programming Language
http://www.dog-lang.org
Apache License 2.0
0 stars 0 forks source link

Socket-Based Client API #63

Open salmanahmad opened 11 years ago

salmanahmad commented 11 years ago

Update the API to be socket based. The new API will have the following end points:

GET dog/task/<id> POST dog/task/<id>/<channel> SOCKET dog/task/subscribe/<id>

When a viewport renders a template for a task, the client libraries will auto subscribe for changes to the task.

When the client sends a listen the API will "queue" up the listen invocation but then return immediately. The runtime executes on another "thread" from the API server.

Whenever changes are made to the task, a "ping" is sent to all clients subscribed to the task's channel.

Whenever the client receives a "ping" over the socket, it will reload (pull) the task and update any "viewports" that are rendering a template for the task.

Viewports render templates for a task. Whenever a task changes, the viewport will auto-reload the task. Viewports' task can be hardcoded, for example, many applications will have a viewport that will always load the "root" task, but they can also be set programmatically and reloaded(). When a viewport sends a listen to the server, and there are updates to that task, the entire viewport is replace with the new template. This is true for both on and on each waits.

There is also a nested {{viewport}} helper that will allow nested templates for tasks that are displayed to the clients.

salmanahmad commented 11 years ago

As another quick point, when a task enters the waiting state, it will associate the list of channels it is waiting on in the meta data. If the API gets a "listen" to a task that is not currently waiting (i.e. it has been restarted by a previous user input) or gets a "listen" on a channel that the task is not waiting on in the meta data, then it will be ignored. This eliminates any "split-brain" issues and also avoids "spam clicking" on buttons.

salmanahmad commented 11 years ago

Another thing that is important is that tasks have a "spawn ancestry" list. When you attempt to render a viewport for a task, the task will start by rendering the top level task in the ancestry list first and follow it down, executing nested templates as it goes.

Forked tasks do not represent a "spawned" task.

salmanahmad commented 11 years ago

Syntax for viewports: {{viewport <task-name-no-displays-needed> on="<auto-trigger>" with="<data for on>" }}

Viewports can take a task id as well as a "name".

The following additional properties need to be added to the task object:

nonce - Used to avoid out of date submission to listens name - Use to name functions state - Can now include a "closure" state