Giter Site home page Giter Site logo

noflo-runtime-base's Introduction

NoFlo Base Runtime

Base implementation of FBP protocol for NoFlo. Used by libraries implementing different transports, like noflo-runtime-websocket and noflo-runtime-postmessage.

Changes

  • 0.13.1 (December 14th 2020)

    • registerGraph method now returns a Promise
  • 0.13.0 (December 14th 2020)

    • Adapted to Promises functionality in NoFlo 1.4
  • 0.12.0 (November 25th 2020)

    • Added support for the Trace sub-protocol
    • Removed the local pseudo-Flowtrace implementation in favor of the proper Flowtrace library
    • Switched to the new NoFlo 1.3 network options scheme
  • 0.11.10 (November 19th 2020)

    • Fixed handling of changegroup commands
  • 0.11.9 (November 16th 2020)

    • Compatibility improvements with the fbp-protocol test suite
  • 0.11.7 (November 16th 2020)

    • Compatibility with the TypeScript version of fbp-graph
  • 0.11.6 (November 11th 2020)

    • Fixed sending of object payloads via network:data message
    • Fixed library name incompatibility with fbp-protocol
  • 0.11.5 (September 25th 2020)

    • fbp-spec graphs (fixture.xx) are now special-cased so that they don't get registered as components
    • Fixed issue with namespacing graph components
  • 0.11.4 (September 23rd 2020)

    • Component sub-protocol now also emits component tests at setSource
  • 0.11.3 (September 23rd 2020)

    • The NoFlo runtime now handles graph names in a more consistent manner. When graphs/networks are instantiated by the runtime, they are always namespaced
  • 0.11.2 (September 18th 2020)

    • The runtime now emits a ready or error after construction dependending on main graph initialization result
  • 0.11.1 (September 4th 2020)

    • The runtime instantiates networks now for all graphs in the current project in addition to the "main" graph
  • 0.11.0 (September 1st 2020)

    • NoFlo Networks are now instantiated for all graphs, meaning that graph operations fail more gracefully and networks start faster
    • Ported from CoffeeScript to ES6
  • 0.10.5 (February 23rd 2019)

    • Added runtime.component lifecycle event updated when component sources are modified via the protocol. Can be used to persist changes
    • Added runtime.graph lifecycle event updated when a graph is modified via the protocol. Can be used to persist changes
  • 0.10.4 (December 1st 2018)

    • Typo fix for registering a main graph
  • 0.10.3 (December 1st 2018)

    • Made the defaultGraph option use the project's actual namespace and graph name instead of hardcoded default/main
  • 0.10.2 (March 30th 2018)

    • Ensured that network:begingroup and network:endgroup include the required group property
  • 0.10.1 (March 29th 2018)

    • Made runtime:ports signal compatible with the FBP Protocol schema
    • Added responses to renameinport and renameoutport requests
  • 0.10.0 (March 22nd 2018)

    • Added support for FBP Protocol 0.7
    • Changed the component:component message to conform with the FBP protocol schema
    • Ensured all graph protocol messages get a response
    • Added support for the network:control, network:status, and network:data capabilities
    • Added runtime:packetsent response to runtime:packet requests
    • Added error responses for unsupported subprotocols and commands
    • Improved error handling when trying to receive packets from unavailable exported outports
  • 0.9.3 (February 19th 2018)

    • Improved error handling when starting a new network

noflo-runtime-base's People

Contributors

automata avatar bergie avatar dependabot[bot] avatar djdeath avatar ensonic avatar greenkeeper[bot] avatar greenkeeperio-bot avatar jonnor avatar llandwerlin-intel avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar

noflo-runtime-base's Issues

Flash runtime support

It would be nice to have the ability to tell the runtime to "flash" its graphs, so it can restore the last flashed state whenever it is restarted.

When component loading fails, does not send componentsready

This means that if a single component fails to load, then any FBP client which expects componentsready, like Flowhub or fbp-spec will fails to talk to the runtime.

Because there is no stack associated with the error (just message), and the message does not contain the name of the faulty component, it is essentially impossible to find the issue from the client-side.
Need to use a debugger on the remote end...

An in-range update of grunt-noflo-browser is breaking the build 🚨

The devDependency grunt-noflo-browser was updated from 1.6.0 to 1.7.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

grunt-noflo-browser is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details
  • continuous-integration/travis-ci/push: The Travis CI build failed (Details).

Commits

The new version differs by 21 commits.

  • 764baf6 Release 1.7.0
  • 58728df Merge pull request #41 from noflo/greenkeeper/babel-loader-8.0.0
  • faa7a70 Update appveyor Node version
  • ff1e2bc Update babel env
  • f59a123 Merge pull request #48 from noflo/greenkeeper/webpack-4.28.3
  • e493bb9 Merge pull request #45 from noflo/greenkeeper/grunt-contrib-jshint-2.0.0
  • 119cc90 chore(package): update webpack to version 4.28.3
  • 0b69cd2 chore(package): update grunt-contrib-jshint to version 2.0.0
  • 51b73b2 Merge pull request #43 from noflo/greenkeeper/grunt-contrib-clean-2.0.0
  • 99db276 Merge branch 'master' into greenkeeper/grunt-contrib-clean-2.0.0
  • 13d5ad2 Merge pull request #42 from noflo/greenkeeper/grunt-contrib-connect-2.0.0
  • e2983f4 chore(package): update grunt-contrib-clean to version 2.0.0
  • 10e1db6 chore(package): update grunt-contrib-connect to version 2.0.0
  • feaa2c5 fix(package): update babel-loader to version 8.0.0
  • fb7b9ab Merge pull request #38 from noflo/greenkeeper/update-to-node-10

There are 21 commits in total.

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

flowtrace: Make buffer circular, with adjustable limit

Right now just keeps data forever, which will blow up... This basically prevents enabling in production scenarios.

Configuration options:

  • maxMemory: Maximum memory usage in megabytes. Will need to estimate this by introspecting JS the structure. Default: 50 MB?
  • storageDuration: Time to (try to) preserve events for. Anything from before this we can drop completely. Default: 10 minutes?

Both should be settable using envvars.

When hitting limits we'd like to preserve as much data as useful. Possibly compacting strategy, continuing to next step if not enough memory is freed. Within each step, always starting from oldest event:

  1. Trim payloads (but keep events) from before storageDuration
  2. Trim events from before storageDuration.
  3. Trim payloads from inside
  4. Trim events from inside

We should probably compact to quite a bit below limit when , to avoid triggering this every time when 'riding' the limit. Maybe down to 75% ?

Possibly we should store these 'compaction events' into the trace itself. Timestamp, memory before, memory after, number of events removed (in each category?)?

Transmit component icon changes

There is a use case for components changing their icons in runtime, for example to visualize something in the component's internal state (imagine showing a different icon for flow/Gate when it is open or closed, or when a microflo LED is lit up or not).

This is related to a particular node in a running graph, not the component itself.

flowtrace: Missing tests

Need at least core happy-case, verifying contents of resulting trace.
Plus something excersising the buffer compaction code (#34)

An in-range update of mocha is breaking the build 🚨

Version 5.0.1 of mocha was just published.

Branch Build failing 🚨
Dependency mocha
Current Version 5.0.0
Type devDependency

This version is covered by your current version range and after updating it in your project the build failed.

mocha is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details
  • continuous-integration/travis-ci/push The Travis CI build failed Details

Commits

The new version differs by 15 commits.

  • 09ce746 Release v5.0.1
  • 70027b6 update changelog for v5.0.1 [ci skip]
  • 44aae9f add working wallaby config
  • 412cf27 [Update] license year
  • b7377b3 rename help-wanted to "help wanted" in stale.yml
  • d975a6a fix memory leak when run in v8; closes #3119
  • 3509029 update .gitignore to only ignore root mocha.js [ci skip]
  • b57f623 fix: When using --delay, .only() no longer works. Issue #1838
  • cd74322 Slight copy update on docs for test directory
  • f687d2b update docs for the glob
  • 14fc030 Add all supported wallaby editors
  • 2e7e4c0 rename "common-mistake" label to "faq"
  • bca57f4 clarify docs on html, xunit and 3p reporters; closes #1906
  • 2fe2d01 Revert "fix travis "before script" script"
  • c0ac1b9 fix travis "before script" script

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

How to use this?

I'm now planning to create a basic UI, and JSON stringify result, send to backend using custom REST API, and use another API to execute flow on backend.

Can this package save me some time? How to use this?

graph:addnode responds before ready causing race condition

graph:addnode request sends a response immediately on receiving instead of waiting for the async action to be completed. This causes race conditions when for example followed by graph:addedge commands that refer to the added node, since the node is not always finished setting up.

This happens easily with fbp-spec on computers with a little bit slow I/O. Or anything else using fbpClient.graph.send

Right now the noflo-nodejs runtime crashes when this happens

 No process defined for outbound node readSpaces
at Network.addEdge (/home/jon/work/flowhub/bigiot-bridge/node_modules/noflo/lib/Network.js:542:25)
    at processOps (/home/jon/work/flowhub/bigiot-bridge/node_modules/noflo/lib/Network.js:381:31)
    at Graph.<anonymous> (/home/jon/work/flowhub/bigiot-bridge/node_modules/noflo/lib/Network.js:408:18)
    at Graph.emit (events.js:187:15)
    at Graph.addEdge (/home/jon/work/flowhub/bigiot-bridge/node_modules/fbp-graph/lib/Graph.js:587:12)
    at GraphProtocol.addEdge (/home/jon/work/flowhub/bigiot-bridge/node_modules/noflo-runtime-base/protocol/Graph.js:368:18)
    at GraphProtocol.receive (/home/jon/work/flowhub/bigiot-bridge/node_modules/noflo-runtime-base/protocol/Graph.js:40:21)
    at WebSocketRuntime.receive (/home/jon/work/flowhub/bigiot-bridge/node_modules/noflo-runtime-base/Base.js:183:27)
    ...
 +1ms
events.js:167
      throw er; // Unhandled 'error' event
      ^
Error: read ECONNRESET
    at TCP.onread (net.js:659:25)

An in-range update of grunt-noflo-browser is breaking the build 🚨

Version 1.4.1 of grunt-noflo-browser was just published.

Branch Build failing 🚨
Dependency grunt-noflo-browser
Current Version 1.4.0
Type devDependency

This version is covered by your current version range and after updating it in your project the build failed.

grunt-noflo-browser is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details
  • continuous-integration/travis-ci/push The Travis CI build failed Details

Commits

The new version differs by 2 commits.

  • bd0bf7c Bump
  • 9cde560 chore(package): update noflo-component-loader to version 0.1.2

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

flowtrace: Clone data as it is outputted

Possibly do the serialization to JSON right away when stuffing into events ?

Right now get some issues where there is a shared ref being passed in connection, and it is being modified, then all events only see the last state (for some events not reflecting state at time of event).

Flowtrace: Make easy to use with ComponentLoader

Primarily for existing tests in Mocha etc, where one does not want to rewrite them to fbp-spec to get flowtrace support

Could maybe be a monkeypatch of noflo.ComponentLoader ?
Could also have some API for fbp-spec-mocha to use, in order to also provide integrated Flowtrace support. Ref flowbased/fbp-spec#34

Typescript defination

This is guessed using ChatGPT, and fix some any by me.

/* eslint-disable unicorn/prevent-abbreviations */
/* eslint-disable unicorn/prefer-event-target */

declare module 'noflo-runtime-base' {
  // noflo-runtime-base/blob/master/src/protocol/Component.js
  import { EventEmitter } from 'events';
  import { ComponentLoader } from 'noflo';
  import { Graph } from 'fbp-graph';

  interface PortDef {
    addressable?: boolean;
    default?: any;
    description?: string;
    id: string;
    required?: boolean;
    schema?: string;
    type: string;
    values?: any[];
  }

  interface Instance {
    description: string;
    getIcon?: () => string;
    inPorts: Record<string, any>;
    isSubgraph: () => boolean;
    outPorts: Record<string, any>;
  }

  interface ComponentProtocol extends EventEmitter {
    getLoader: (baseDir: string, options?: Record<string, any>) => ComponentLoader;

    getSource: (payload: any, context: any) => void;

    listComponents: (payload: any, context: any) => void;

    loaders: Record<string, ComponentLoader>;

    processComponent: (loader: ComponentLoader, component: string, context: any) => Promise<any>;

    processPort: (portName: string, port: any) => PortDef;

    receive: (topic: string, payload: any, context: any) => any;

    registerGraph: (id: string, graph: Graph, context: any) => void;

    send: (topic: string, payload: any, context: any) => any;

    sendComponent: (component: string, instance: Instance, context: any) => void;

    setSource: (payload: any, context: any) => void;

    transport: BaseTransport;
  }

  const ComponentProtocol: {
    new(transport: BaseTransport): ComponentProtocol;
    initClass: () => void;
  };

  // noflo-runtime-base/blob/master/src/protocol/Graph.js

  import { EventEmitter } from 'events';
  export interface Node {
    component?: string;
    id: string;
    metadata?: any;
  }

  export interface Edge {
    metadata?: any;
    src: {
      index?: number;
      node: string;
      port: string;
    };
    tgt: {
      index?: number;
      node: string;
      port: string;
    };
  }

  export interface Initial {
    metadata?: any;
    src: {
      data: any;
    };
    tgt: {
      index?: number;
      node: string;
      port: string;
    };
  }

  export interface Group {
    metadata?: any;
    name: string;
    nodes: string[];
  }

  export interface Port {
    metadata?: any;
    port: string;
    process: string;
  }

  export interface Payload {
    description?: string;
    from?: string;
    graph: string;
    icon?: string;
    id?: string;
    library?: string;
    main?: boolean;
    metadata?: any;
    name?: string;
    node?: string;
    nodes?: string[];
    port?: string;
    public?: string;
  }

  enum Topic {
    AddEdge = 'addedge',
    AddGroup = 'addgroup',
    AddInitial = 'addinitial',
    AddInport = 'addinport',
    AddNode = 'addnode',
    AddOutport = 'addoutport',
    ChangeEdge = 'changeedge',
    ChangeGroup = 'changegroup',
    ChangeNode = 'changenode',
    Clear = 'clear',
    Error = 'error',
    RemoveEdge = 'removeedge',
    RemoveGroup = 'removegroup',
    RemoveInitial = 'removeinitial',
    RemoveInport = 'removeinport',
    RemoveNode = 'removenode',
    RemoveOutport = 'removeoutport',
    RenameGroup = 'renamegroup',
    RenameInport = 'renameinport',
    RenameNode = 'renamenode',
    RenameOutport = 'renameoutport',
  }

  class GraphProtocol extends EventEmitter {
    transport: BaseTransport;
    graphs: Record<string, Graph>;

    constructor(transport: BaseTransport);
    send(topic: string, payload: Payload, context: Context): any;
    sendAll(topic: string, payload: Payload): any;
    receive(topic: GraphProtocolCommands, payload: Payload, context: Context): void;
    resolveGraph(payload: Payload, context: Context): any;
    getLoader(baseDirectory: string): any;
    sendGraph(id: string, graph: Graph, context: Context): any;
    initGraph(payload: Payload, context: Context): void;
    registerGraph(id: string, graph: Graph, context?: Context, propagate?: boolean): Promise<any>;
    subscribeGraph(id: string, graph: Graph, context: Context): void;
    addNode(graph: Graph, node: Node, context: Context): void;
    removeNode(graph: Graph, payload: Payload, context: Context): void;
    renameNode(graph: Graph, payload: Payload, context: Context): void;
    changeNode(graph: Graph, payload: Payload, context: Context): void;
    addEdge(graph: Graph, edge: Edge, context: Context): void;
    removeEdge(graph: Graph, edge: Edge, context: Context): void;
    changeEdge(graph: Graph, edge: Edge, context: Context): void;
    addInitial(graph: Graph, payload: Initial, context: Context): void;
    removeInitial(graph: Graph, payload: Initial, context: Context): void;
    addInport(graph: Graph, payload: Payload, context: Context): void;
    removeInport(graph: Graph, payload: Payload, context: Context): void;
    renameInport(graph: Graph, payload: Payload, context: Context): void;
    addOutport(graph: Graph, payload: Payload, context: Context): void;
    removeOutport(graph: Graph, payload: Payload, context: Context): void;
    renameOutport(graph: Graph, payload: Payload, context: Context): void;
    addGroup(graph: Graph, payload: Group, context: Context): void;
    removeGroup(graph: Graph, payload: Payload, context: Context): void;
    renameGroup(graph: Graph, payload: Payload, context: Context): void;
    changeGroup(graph: Graph, payload: Group, context: Context): void;
  }

  // noflo-runtime-base/blob/master/src/protocol/Runtime.js

  declare function sendToInport(port: any, event: string, payload: any): void;
  declare function findPort(network: Network | null, name: string, inPort: boolean): any | null;

  interface PortPayload {
    addressable: boolean;
    description: string | undefined;
    id: string;
    required: boolean;
    type: string;
  }

  declare function portToPayload(pub: string, internal: any, network: Network | null, inPort: boolean): PortPayload;
  declare function portsPayload(name: string, network: Network | null): any;

  type OutputSockets = Record<string, InternalSocket>;

  interface RuntimeProtocolOptions {
    capabilities?: string[];
    id?: string;
    label?: string;
    namespace?: string;
    repository?: string;
    repositoryVersion?: string;
  }

  type RuntimeProtocolConstructor = new(transport: BaseTransport) => RuntimeProtocol;

  export interface RuntimeProtocol extends EventEmitter {
    getRuntime(request: any, context: any): any[];
    getRuntimeDefinition(): RuntimeProtocolOptions;
    mainGraph: string | null;

    outputSockets: OutputSockets;
    receive(topic: string, payload: any, context: any): any;
    registerNetwork(name: string, network: Network): void;
    send(topic: string, payload: any, context: any): any;
    sendAll(topic: string, payload: any): any;
    sendError(err: Error, context: any): any;
    sendPacket(payload: any): Promise<void>;
    sendPorts(name: string, network: Network | null, context: any): any;
    setMainGraph(id: string): void;
    subscribeExportedPorts(name: string, network: Network, add: boolean): void;
    subscribeOutPorts(name: string, network: Network, add?: boolean): void;
    subscribeOutdata(graphName: string, network: Network, add: boolean): void;
    transport: BaseTransport;
  }

  /// noflo-runtime-base/blob/master/src/protocol/Network.js

  interface SocketEvent {
    data: any;
    datatype?: string;
    group?: string;
    id: string;
    // Replace with a more accurate type if known
    metadata?: any;
    schema?: string;
    socket: any;
    // Replace with a more accurate type if known
    subgraph?: string; // Replace with a more accurate type if known
  }

  interface Edge {
    src: any; // Replace with a more accurate type if known
    tgt: any; // Replace with a more accurate type if known
  }

  interface Connection {
    port: string;
    process: { id: string };
  }

  interface Network {
    // Replace with a more accurate type if known
    isRunning: () => boolean;
    isStarted: () => boolean;
    on: (event: string, callback: (event: any) => void) => void;
    setDebug: (enable: boolean) => void;
    start: () => Promise<any>;
    // Replace with a more accurate type if known
    stop: () => Promise<any>; // Replace with a more accurate type if known
  }

  export class NetworkProtocol extends EventEmitter {
    constructor(transport: BaseTransport);
    send: (topic: string, payload: any, context: any) => void; // Replace with a more accurate type if known
    sendAll: (topic: string, payload: any) => void; // Replace with a more accurate type if known
    receive: (topic: string, payload: any, context: any) => void; // Replace with a more accurate type if known
    resolveGraph: (payload: any, context: any) => any; // Replace with a more accurate type if known
    getNetwork: (graphName: string) => Network | null;
    updateEdgesFilter: (graph: Graph, payload: any, context: any) => void; // Replace with a more accurate type if known
    eventFiltered: (graph: string, event: SocketEvent) => boolean;
    initNetwork: (graph: Graph, graphName: string, context: any) => Promise<Network>; // Replace with a more accurate type if known
    subscribeNetwork: (network: Network, graphName: string, context: any) => void; // Replace with a more accurate type if known
    startNetwork: (graph: Graph, payload: any, context: any) => void; // Replace with a more accurate type if known
    stopNetwork: (graph: Graph, payload: any, context: any) => void; // Replace with a more accurate type if known
    debugNetwork: (graph: Graph, payload: any, context: any) => void; // Replace with a more accurate type if known
    getStatus: (graph: Graph, payload: any, context: any) => void; // Replace with a more accurate type if known
  }

  // noflo-runtime-base/blob/master/src/protocol/Trace.js

  type TopicType = 'start' | 'stop' | 'dump' | 'clear' | string;

  interface Payload {
    buffersize?: number;
    flowtrace?: any;
    graph: string;
    type?: string;
  }

  type Context = Record<string, any>;

  interface Network {
    getNetwork(graph: string): Network | null;
    setFlowtrace(flowtrace: Flowtrace | null, graphName?: string, flag?: boolean): any;
  }

  interface Runtime {
    getRuntimeDefinition(): any;
    network: Network;
  }

  export class TraceProtocol {
    transport: BaseTransport;
    traces: Record<string, Flowtrace>;

    constructor(transport: BaseTransport);
    send(topic: TopicType, payload: Payload, context: Context): Promise<void>;
    sendAll(topic: TopicType, payload: Payload): Promise<void>;
    receive(topic: TopicType, payload: Payload, context: Context): void;
    resolveGraph(payload: Payload, context: Context): Flowtrace | null;
    startTrace(graphName: string, network: Network, buffersize: number): Flowtrace;
    start(payload: Payload, context: Context): void;
    stop(payload: Payload, context: Context): void;
    dump(payload: Payload, context: Context): void;
    clear(payload: Payload, context: Context): void;
  }

  // noflo-runtime-base/blob/master/src/Base.js
  export interface BaseTransportOptions {
    capabilities?: string[];
    captureOutput?: boolean;
    defaultGraph?: Graph;
    defaultPermissions?: string[];
    namespace?: string;
    permissions?: Record<string, string[]>;
  }

  enum Protocol {
    Component = 'component',
    Graph = 'graph',
    Network = 'network',
    Runtime = 'runtime',
    Trace = 'trace',
  }

  enum CanInputTopic {
    debug = 'debug',
    edges = 'edges',
    getruntime = 'getruntime',
    getsource = 'getsource',
    getstatus = 'getstatus',
    list = 'list',
    packet = 'packet',
    source = 'source',
    start = 'start',
    stop = 'stop',
  }

  export default class BaseTransport extends EventEmitter {
    constructor(options: BaseTransportOptions);
    version: string;
    component: Component;
    graph: Graph;
    network: Network;
    runtime: Runtime;
    trace: Trace;
    context: any;
    options: BaseTransportOptions;

    /**
     * Generate a name for the main graph
     */
    getGraphName(graph: Graph): string;
    /**
     * Check if a given user is authorized for a given capability

    @param [Array] Capabilities to check
    @param [String] Secret provided by user */
    canDo(capability: string | string[], secret: string): boolean;
    /**
     * Check if a given user is authorized to send a given message
     */
    canInput(protocol: Protocol, topic: CanInputTopic, secret: string): boolean;
    /**
     * Get enabled capabilities for a user

    @param [String] Secret provided by user */
    getPermitted(secret: string): string[];
    /**
     * Send a message back to the user via the transport protocol.

    Each transport implementation should provide their own implementation
    of this method.

    The context is usually the context originally received from the
    transport with the request. This could be an iframe origin or a
    specific WebSocket connection.

    @param [String] Name of the protocol
    @param [String] Topic of the message
    @param [Object] Message payload
    @param [Object] Message context, dependent on the transport */
    send(protocol: string, topic: string, payload: any, context?: any): void;
    /*
    *all users*  via the transport protocol

    The transport should verify that the recipients are authorized to receive
    the message by using the `canDo` method.

    Like send() only it sends to all.

    @param [String] Name of the protocol
    @param [String] Topic of the message
    @param [Object] Message payload
    @param [Object] Message context, dependent on the transport */
    sendAll(protocol?: string, topic?: string, payload?: any, context?: any): void;
    /**
     * This is the entry-point to actual protocol handlers. When receiving
    a message, the runtime should call this to make the requested actions
    happen

    The context is originally received from the transport. This could be
    an iframe origin or a specific WebSocket connection. The context will
    be utilized when sending messages back to the requester.

    @param [String] Name of the protocol
    @param [String] Topic of the message
    @param [Object] Message payload
    @param [Object] Message context, dependent on the transport */
    receive(protocol: string, topic: string, payload?: any, context?: any): void;
  }

  export function direct(options: object): void;
}

An in-range update of grunt-noflo-browser is breaking the build 🚨

Version 1.5.1 of grunt-noflo-browser was just published.

Branch Build failing 🚨
Dependency grunt-noflo-browser
Current Version 1.5.0
Type devDependency

This version is covered by your current version range and after updating it in your project the build failed.

grunt-noflo-browser is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details
  • continuous-integration/travis-ci/push The Travis CI build failed Details

Commits

The new version differs by 3 commits.

  • dbede0b Bump
  • 18c133c Add support for transpiling noflo-runtime-xx to ES5
  • 96bd837 Update fixture components to NoFlo 1.0 versions

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

flowtrace: Also save subgraphs

Currently we only persist the top-level graph. Which makes Flowhub less than useful when replaying because it does not understand the subgraphs.

Store into 'graphs' key, or 'components'. Need to avoid being confused with top-level networks.

Error objects serialized as {}

In runtime:packet payloads an Error object sent from NoFlo gets serialized as {}. This breaks checking error (type/messages) using fbp-spec.

This is possibly also the case for network:packet, not certain. Could also be the case for Flowtrace serialization.

Version 10 of node.js has been released

Version 10 of Node.js (code name Dubnium) has been released! 🎊

To see what happens to your code in Node.js 10, Greenkeeper has created a branch with the following changes:

  • Added the new Node.js version to your .travis.yml

If you’re interested in upgrading this repo to Node.js 10, you can open a PR with these changes. Please note that this issue is just intended as a friendly reminder and the PR as a possible starting point for getting your code running on Node.js 10.

More information on this issue

Greenkeeper has checked the engines key in any package.json file, the .nvmrc file, and the .travis.yml file, if present.

  • engines was only updated if it defined a single version, not a range.
  • .nvmrc was updated to Node.js 10
  • .travis.yml was only changed if there was a root-level node_js that didn’t already include Node.js 10, such as node or lts/*. In this case, the new version was appended to the list. We didn’t touch job or matrix configurations because these tend to be quite specific and complex, and it’s difficult to infer what the intentions were.

For many simpler .travis.yml configurations, this PR should suffice as-is, but depending on what you’re doing it may require additional work or may not be applicable at all. We’re also aware that you may have good reasons to not update to Node.js 10, which is why this was sent as an issue and not a pull request. Feel free to delete it without comment, I’m a humble robot and won’t feel rejected 🤖


FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.