New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Externalize Device Configurations #38

Open
qdot opened this Issue Sep 4, 2017 · 1 comment

Comments

Projects
None yet
1 participant
@qdot
Member

qdot commented Sep 4, 2017

There's not much of a reason to compile in device definitions, and externalizing them would mean less software version revs and an easier way for people to test. Make a JSON file with device definitions that can be loaded across servers.

@qdot qdot self-assigned this Sep 4, 2017

@qdot qdot added the Epic label Sep 4, 2017

@qdot

This comment has been minimized.

Show comment
Hide comment
@qdot

qdot Nov 17, 2017

Member

Before I post the example, I should mention that I don't see device definition formats here being part of the spec. This just makes life slightly easier for us when doing our reference implementations. If people want to follow it, fine, if they want to do their own thing, also fine.

Here's a quick version of what I think these should look like:

[
  {
    "protocol": "lovense",
    "type": "bluetooth",
    "names": ["LVS-A001", "LVS-C011"],
    "services": {
      "6e400001-b5a3-f393-e0a9-e50e24dcca9e": {
        "tx": "6e400002-b5a3-f393-e0a9-e50e24dcca9e",
        "rx": "6e400003-b5a3-f393-e0a9-e50e24dcca9e"
      },
      "0000fff0-0000-1000-8000-00805f9b34fb": {
        "tx": "0000fff2-0000-1000-8000-00805f9b34fb",
        "rx": "0000fff1-0000-1000-8000-00805f9b34fb"
      }
    }
  },
  {
    "protocol": "realtouch",
    "type": "usb",
    "vid": 1234,
    "pid": 1234
  },
  {
    "protocol": "et312",
    "type": "serial"
  }
]

A quick informal breakdown 'cause I don't want to start writing the schema before at least getting a little feedback:

  • Protocol refers to the protocol things talk
  • Type refers to communication line type. So far, I only have usb/serial/bluetooth for this. Makes it easier to parse what we should do with the identifier info.
  • Identifiers:
    • Bluetooth
      • Names: All of the names for devices. Possibly worth wildcarding?
      • Services: Object with service ID/characteristic ID pairings. Main problem here is going to be devices with multiple services, which I believe may already be a thing in some of the new kiiroo toys. May be worth naming services AND their characteristics?
    • USB
      • Pretty easy. Just VID/PID.
    • Serial
      • We don't get to know that, so just say "serial".

@blackspherefollower @NZSmartie any comments/suggestions?

Member

qdot commented Nov 17, 2017

Before I post the example, I should mention that I don't see device definition formats here being part of the spec. This just makes life slightly easier for us when doing our reference implementations. If people want to follow it, fine, if they want to do their own thing, also fine.

Here's a quick version of what I think these should look like:

[
  {
    "protocol": "lovense",
    "type": "bluetooth",
    "names": ["LVS-A001", "LVS-C011"],
    "services": {
      "6e400001-b5a3-f393-e0a9-e50e24dcca9e": {
        "tx": "6e400002-b5a3-f393-e0a9-e50e24dcca9e",
        "rx": "6e400003-b5a3-f393-e0a9-e50e24dcca9e"
      },
      "0000fff0-0000-1000-8000-00805f9b34fb": {
        "tx": "0000fff2-0000-1000-8000-00805f9b34fb",
        "rx": "0000fff1-0000-1000-8000-00805f9b34fb"
      }
    }
  },
  {
    "protocol": "realtouch",
    "type": "usb",
    "vid": 1234,
    "pid": 1234
  },
  {
    "protocol": "et312",
    "type": "serial"
  }
]

A quick informal breakdown 'cause I don't want to start writing the schema before at least getting a little feedback:

  • Protocol refers to the protocol things talk
  • Type refers to communication line type. So far, I only have usb/serial/bluetooth for this. Makes it easier to parse what we should do with the identifier info.
  • Identifiers:
    • Bluetooth
      • Names: All of the names for devices. Possibly worth wildcarding?
      • Services: Object with service ID/characteristic ID pairings. Main problem here is going to be devices with multiple services, which I believe may already be a thing in some of the new kiiroo toys. May be worth naming services AND their characteristics?
    • USB
      • Pretty easy. Just VID/PID.
    • Serial
      • We don't get to know that, so just say "serial".

@blackspherefollower @NZSmartie any comments/suggestions?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment