The Frame System Design Language (FSDL) and Runtime about frame_transpiler HOT 3 OPEN

@walkie Interested in your thoughts on this basic concept. I am aiming to implement reference implementations in a few languages and target environments to validate the idea. Thoughts? Any obvious problems with the idea?

from frame_transpiler.

To be honest, I'm a bit out of my depth here! The domain seems potentially huge, which makes me a bit wary. However, seeing a reference implementation might help to clarify things.

One question about channels: Do these subsume the existing actions and event handlers? If not, should they? That is, should there be a common way of defining and interacting with these various forms of message passing?

Currently, actions are exclusively Frame->Host and events are primarily Host->Frame. However, there's a need for Frame->Frame (i.e. something like subroutines, which can be simulated with events but have some limitations and pollute the external interface), and ideally Frame->other-Frame (i.e. communication between state machines, which currently requires some glue code in the interface).

If the "channel" metaphor supported all of the possible combinations, perhaps with syntactic sugar for the common cases currently supported by actions and events, that could be nice from a language design and implementation perspective.

from frame_transpiler.

To be honest so am I :).

And yes the goal is to identify patterns/interfaces/symbology that works for any-to-any communication. The hope is that there can be a standardized approach to all the typical communications objects/protocols (http, sockets (tcp, udp), pipes, rpc, internal pub/sub libraries etc).

I don't believe this changes anything about event handlers and actions as they exist now. However new concepts/objects/notation/patterns would exist that would expand what was in the Frame universe. Some of these would be declared/referenced from a Frame spec. Others such as the SOS is just part of the runtime environment.

In general I'm hoping controllers can be removed from actually "doing" anything. Instead, they make decisions about events that come in and send out events about their decisions. I'm lumping all executive functions (calling APIs, changing global state etc) into an "Executor" object. The only difference here is that the controller doesn't make the low level call. Instead it decides what should be done and sends a message to the Executor which does the environment specific dirty work. This segregation between "decider" and "doer" code would make this approach completely generic and (theoretically) portable.

In terms of usage of a channel, I think conceptually at a high level it is pretty simple - a) polling or b) notifications to read data and write is write which succeeds or doesn't. However each of those communication objects works differently under the hood. Differences off the top of my head include buffering, directionality, sync/async and I'm sure many more.

I'm hoping that the FrameChannel object would paper over all of that and make them all work in a consistent way. It may not really matter in the end but it would be nice if possible.

As for notation I'm kind of in love with the <@> token to mean "Frame Channel". So creating a channel in Frame would look like this:

var global_channel:<@> = <@>(config_data)

I'm thinking that <@>(config_data) transpiles to a FrameChannel class/type that has a factory function that takes the config data and returns a standardized FrameChannel interface that holds a reference to the concrete comm mechanism object requested in the config data.

With regard to I/O, if the read config specifies to be notified about (rather than polling for) incoming messages then part of the config info must be what event to send to the controller.

Alternatively, if notification was desired but just as a pass through then perhaps a general purpose interface method on the controller might be interesting. I'm tentatively thinking dispatch(FrameEvent) as the standard interface method, but TBD. The FrameChannel would need to convert the wire data into a FrameEvent (rather than the controller interface) and directly "inject" the FrameEvent into the controller. I think this would be straightforward for RPC but would need some standardization for HTTP and other protocols.

from frame_transpiler.