Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jun 16 2015 01:01

    joshperry on streams

    Emit checksum_error instead of … (compare)

  • Jun 16 2015 01:00

    joshperry on streams

    Emit checksum_error instead of … (compare)

  • Jan 22 2015 23:39

    joshperry on streams

    Do not overwrite an explicit fr… (compare)

  • Jan 18 2015 23:35

    joshperry on streams

    Provide method to detect if the… (compare)

  • Jan 15 2015 13:22

    joshperry on streams

    Revert event change (compare)

  • Jan 15 2015 13:19

    joshperry on streams

    npm ver 0.3.8 fixed #20 Added depts and 3 more (compare)

  • Jan 15 2015 12:34

    joshperry on master

    npm ver 0.3.8 fixed #20 Added depts (compare)

  • Jan 14 2015 00:01

    joshperry on streams

    Right-size the frame buffer (compare)

  • Jan 13 2015 22:47

    joshperry on streams

    Right-size the frame buffer (compare)

  • Jan 13 2015 03:06

    joshperry on streams

    Do not reuse parse buffer (compare)

  • Jan 12 2015 18:19

    joshperry on streams

    Add Create Source Route support (compare)

  • Jan 12 2015 08:20

    joshperry on streams

    Fix parseFrame to take whole fr… (compare)

  • Jan 12 2015 03:40
    joshperry closed #1
  • Jan 12 2015 03:37

    joshperry on streams

    Update buffer-builder dep Handle the different allowed fr… Implement parsers for send fram… and 3 more (compare)

Joshua Perry
@joshperry
Hey Jan, I'd really like to get some integration with streams to make it easier to chain the flow of data from sources like Sockets, WebSocket, etc.
I noticed you have a couple other repos that talk about streams, just wanted to see if we could chat for a minute on any ideas you might have. I have some time to spend on this and I'd like to put something down that is generally useful.
I see two interesting place that streams could be used. First is streaming data into xbee-api instead of using the parser idiom. It's more idiomatic Node, and it should make it much easier for users to compose connectivity to their XBee network.
The one thing I'm thinking we need some kind of 'Standardization' on is providing the streams to the consumers.
Joshua Perry
@joshperry
Since stream creation and management is not part of the stream interface, a stream is effectively an transient object. When it gets closed or destroyed because of an error, the consuming code has no stream-independent way of re-opening or recreating the stream.
I'm thinking some kind of "Stream Source" that can be provided to a consumer that knows how to open/connect and provide the appropriate stream. The source could also have reconnect, throttling, network connectivity event, and USB plug event logic depending on the type of stream it's providing.
The other option is to basically make libraries Writable streams and then pipe the appropriate stream to them and handle stream failure and closure tangentially. Just thinking about this in my head though, seems like it wouldn't be able to very elegantly handle stream closures and reconnect-style logic.
Joshua Perry
@joshperry
The streams I'm thinking of are to nodes on a network. It would be cool to encapsulate communication with a node on the network into a stream to make the XBee transport, essentially, transparent to libraries that are talking to the hardware on the remote end. Something like the firmata lib would be able to talk to an Arduino over an XBee shield incredibly easily without knowing, or caring, that the stream it's communicating over isn't a direct serial connection.
It would be really cool to be able to aggregate multiple coordinator streams into a router component of some sort. You would then basically have something akin to how net.Socket works. Perhaps an function like net.createConnection that takes the address of the device and returns a stream that routes write requests to the appropriate coordinator and routes frames coming from that node to the appropriate stream.
Joshua Perry
@joshperry
We could possibly provide a way to multiplex multiple connections to the same device as long as the connection was made to specific ZigBee endpoint on the device (like a TCP port). I think connections to streaming endpoints, like the Digi transparent endpoint, to be mutually exclusive... Seems like it would cause some contention issues to have multiple writers to one of those endpoints.