{"action":"created","issue":{"url":"https://api.github.com/repos/jeelabs/folie/issues/50","repository_url":"https://api.github.com/repos/jeelabs/folie","labels_url":"https://api.github.com/repos/jeelabs/folie/issues/50/labels{/name}","comments_url":"https://api.github.com/repos/jeelabs/folie/issues/50/comments","events_url":"https://api.github.com/repos/jeelabs/folie/issues/50/events","html_url":"https://github.com/jeelabs/folie/issues/50","id":230197089,"number":50,"title":"Folie v3 notes","user":{"login":"tve","id":39480,"avatar_url":"https://avatars1.githubusercontent.com/u/39480?v=3","gravatar_id":"","url":"https://api.github.com/users/tve","html_url":"https://github.com/tve","followers_url":"https://api.github.com/users/tve/followers","following_url":"https://api.github.com/users/tve/following{/other_user}","gists_url":"https://api.github.com/users/tve/gists{/gist_id}","starred_url":"https://api.github.com/users/tve/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/tve/subscriptions","organizations_url":"https://api.github.com/users/tve/orgs","repos_url":"https://api.github.com/users/tve/repos","events_url":"https://api.github.com/users/tve/events{/privacy}","received_events_url":"https://api.github.com/users/tve/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":10,"created_at":"2017-05-21T04:56:16Z","updated_at":"2017-05-25T04:40:32Z","closed_at":null,"body":"This issue captures a discussion with JC. Dunno how understandable it is.\r\n\r\nGoals for the JeeNode side:\r\n- support talking to a JeeNode attached via serial (or USB)\r\n- support talking to a JeeNode over RF, using a JeeNode attached via serial as bridge\r\n- support cascading, i.e., running folie locally that talks to a remote folie that has a local serial port\r\n\r\nGoals for the client side:\r\n- support interactive terminal use\r\n- support connections over the network\r\n\r\nFor the network connections:\r\n- support SSH to get encryption\r\n- possibly support telnet for simplicity and ser2net\r\n\r\nRF handling:\r\n- everything is line-oriented, thus both folie and the mecrisp code ensure that lines are sent as a unit, RF packet == line.\r\n- the serial-to-RF bridge understands a simple prefix that is used to distinguish lines that go over RF to a remote mecrisp interpreter from lines that are to/from the bridge node's interpreter\r\n- there is a distinction between RF data packets (such as a temperature measurement) and RF interpreter packets that handle a remote mecrisp interpreter input/output\r\n- for RF data packets one talks to the local bridge and there is no special support in folie (other than prefix filtering, see below):\r\n  - when it receives a packet it outputs a line that starts with `RF>` (RF Data) followed by the packet in hex/base64 followed by some metadata, such as rssi, FEI, etc.\r\n  - when it is sent a line that starts with RF> it interprets the rest as a packet to be sent using a similar format\r\n- the bridge handles ACKs, retransmissions, frequency correction, TX power adjustment\r\n\r\nNew folie features to support client-side network connections:\r\n- add `-l` option to create an SSH listening socket (do we need a telnet option?)\r\n- add `-ssh` option to connect to a remote folie over ssh (or reuse the `-p` option and drop telnet support?)\r\n- add a `!filter <line_prefix>` command to tell folie how to filter lines coming in from serial, this could be omitted initially\r\n\r\nNew folie features to support connecting to a mecrisp interpreter over RF:\r\n- add `!node <id>` command to select which remote node's interpreter to talk to instead of the locally attached one (use `!n 0` or `!n` to switch back to local)o\r\n- to talk to a remote interpreter, folie prefixes lines with `RF.n>`, where n is the node id, so the bridge code can route them\r\n- the bridge code prefixes incoming RF packets from a remote interpreter with `RF.n>` where n is the node id\r\n\r\nNode IDs:\r\n- the bridge perform hex node ID to RF node ID conversion? This would imply a provisioning protocol such that a new node can register with its hex CPU id and obtain a node ID.\r\n- the benefit would be that at the serial port level only the hex ID would be used and the RF-specific node addressing would remain hidden\r\n\r\n"},"comment":{"url":"https://api.github.com/repos/jeelabs/folie/issues/comments/303920589","html_url":"https://github.com/jeelabs/folie/issues/50#issuecomment-303920589","issue_url":"https://api.github.com/repos/jeelabs/folie/issues/50","id":303920589,"user":{"login":"tve","id":39480,"avatar_url":"https://avatars1.githubusercontent.com/u/39480?v=3","gravatar_id":"","url":"https://api.github.com/users/tve","html_url":"https://github.com/tve","followers_url":"https://api.github.com/users/tve/followers","following_url":"https://api.github.com/users/tve/following{/other_user}","gists_url":"https://api.github.com/users/tve/gists{/gist_id}","starred_url":"https://api.github.com/users/tve/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/tve/subscriptions","organizations_url":"https://api.github.com/users/tve/orgs","repos_url":"https://api.github.com/users/tve/repos","events_url":"https://api.github.com/users/tve/events{/privacy}","received_events_url":"https://api.github.com/users/tve/received_events","type":"User","site_admin":false},"created_at":"2017-05-25T04:40:32Z","updated_at":"2017-05-25T04:40:32Z","body":"## Direct attached JeeNode, try 2\r\n\r\nA direct attached JeeNode is attached to a computer running folie via a bidirectional character pipe (serial, usb, ...). Typically most of the activity on a direct attached node happens by interacting with the forth interpreter, including the uploading of source files. In order to facilitate preparing code for an RF node while it is attached a simple fake-rf driver provides packet functionality that is similar to the true RF driver (but has much higher bandwidth and reliability).\r\n\r\nOne proposal for multiplexing the std interactive input and output with data packets is to use SLIP encoding with the detail that data packets start with a character with code >127 while text \"packets\" start with a character with code <128. SLIP encoding means that packets end with a special character. In effect, what this means is that by default 7-bit ascii text can be sent as-is without regard to SLIP. When a data packet is to be sent, it starts with SLIP-END (in effect terminating the text packet), some character >127, the bytes of the packet, and another SLIP-END. After that either another packet can follow or plain text can resume. A nice side-effect is that if the sending party has no notion of SLIP and just sends 7-bit ascii text it all works fine.\r\n"}}
{"actor":{"display_login":"tve"}}