search

UniversalDevicesInc / pg3-python-interface

PG3 Python Interface
MIT License
0 stars 1 forks source link

Making node.primary and node.parent consistent #6

Open Goose66 opened 4 years ago

Goose66 commented 4 years ago

Currently in Polyglot, a nodes parent property is set to the controller node. Of course, each node also has a controller property that points to the controller node. In addition, each node has a primary property that contains the address of the "parent" node for the node in the Admin Consoles hierarchy.

This seems inconsistent and redundant. In the init for my nodes, I have the following code after calling the superclass init():

        # override the parent node with the primary (system) node (defaults to controller)
        self.parent = self.controller.nodes[self.primary]

This retains the hierarchy as shown in Admin Console as well as letting nodes be able to invoke parent node functions simply with self.parent.().

Solutions:

  1. Just set the parent property to the primary node instead of the controller node in the init() - the node already has a controller property.
  2. Refactor the node hierarchy so that each node has a root and parent node properties, with the root node defaulting to the controller and the parent node defaulting to primary (which should be renamed parent), so that the whole hierarchy could be overridden in the nodeserver's code, if desired.
Goose66 commented 4 years ago

Also, we need to figure out what IsPrimary means and whether that should be set automatically or by the nodeserver developer for primary (parent) nodes.

bpaauwe commented 4 years ago

I think some of this got a bit muddled up when the controller class was turned into a node class. If you separate them out, it all makes more sense: node->primary is the address of the nodes parent node->parent points to the node's parent (which should have the address specified in node->primary) node->controller points to the controller (which originally wasn't a node at all)

Because the controller is now also a node, by default most node servers have node->parent and node->controller pointing to the same thing making it seem redundant.

I think #2 is the right solution, but it doesn't need to be renamed, just the node shouldn't default self.parent to self.controller, it should default it to self.controller.nodes[self.primary] as you are doing above.

jimboca commented 4 years ago

The reason this became a little confusing was the initial release of Polyglot V2, if I remember correctly, only one, so the primary, parent and controller were all the same, to but then I requested to have them split up since since parent was not always the primary to better show hierarchy in admin console.

Because the controller is now also a node, by default most node servers have node->parent and node->controller pointing to the same thing making it seem redundant. Many of mine do not have the parent and controller the same.

But, yes, I agree with @bpaauwe the solution 2 looks good, but to retain backwards compatibility may make it confusion, will have to look into it more.

bpaauwe commented 4 years ago

But, yes, I agree with @bpaauwe the solution 2 looks good, but to retain backwards compatibility may make it confusion, will have to look into it more.

A little off topic here, but I think we can both maintain backwards compatibility and create an updated (not fully compatible) API. I'm experimenting with this and It should be possible to "version" the API interface so that if no version is specified, the existing API is used allowing all existing node servers to run without change. But new node servers can be created that specify they want to use the new API and get the enhanced features/capabilities.

Another thing that I'm looking at is making an interface that works with multiple Polyglot versions. If I recall correctly PG3 is going to be Polisy only, not RPi. So it would be nice if a node server could run on PG2 or PG3 without change (and for extra credit, wouldn't it be awesome if the same interface module worked for PGC too). I'm not too far along with this yet, but I find it an interesting challenge.

mkohanim commented 4 years ago

I like this approach very much!

With kind regards,

Michel Kohanim CEO

(p) 818.631.0333 http://www.universal-devices.comhttp://www.universal-devices.com/

From: Bob Paauwe notifications@github.com Sent: Saturday, August 8, 2020 6:27 PM To: UniversalDevicesInc/pg3-python-interface pg3-python-interface@noreply.github.com Cc: Subscribed subscribed@noreply.github.com Subject: Re: [UniversalDevicesInc/pg3-python-interface] Making node.primary and node.parent consistent (#6)

But, yes, I agree with @bpaauwehttps://github.com/bpaauwe the solution 2 looks good, but to retain backwards compatibility may make it confusion, will have to look into it more.

A little off topic here, but I think we can both maintain backwards compatibility and create an updated (not fully compatible) API. I'm experimenting with this and It should be possible to "version" the API interface so that if no version is specified, the existing API is used allowing all existing node servers to run without change. But new node servers can be created that specify they want to use the new API and get the enhanced features/capabilities.

Another thing that I'm looking at is making an interface that works with multiple Polyglot versions. If I recall correctly PG3 is going to be Polisy only, not RPi. So it would be nice if a node server could run on PG2 or PG3 without change (and for extra credit, wouldn't it be awesome if the same interface module worked for PGC too). I'm not too far along with this yet, but I find it an interesting challenge.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/UniversalDevicesInc/pg3-python-interface/issues/6#issuecomment-670992509, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ADMVJPKQADWCDJ4FQFW6CV3R7X3O5ANCNFSM4PVY4VMA.

jimboca commented 4 years ago

I like this, but I'd fear leaving in code to support legacy all in the same codebase. If we simply name the library different for pg3 then any nodeserver just needs to load the correct library. There's good and bad of each way, but personally I like not having all the legacy kept in because it will never go away. But, this means initially developing and supporting a pg3 interface for current nodeservers, then cutting ties and moving forward with breaking changes.

bpaauwe commented 4 years ago

Yeah @jimboca, having to support the legacy code indefinitely is the big negative of this approach. There are a number of other factors that need to be considered too. I think two of the other big ones are:

Ability to run existing node servers on PG3. This does mean someone is going to have to maintain the legacy API for as long as the existing node servers are going to be supported. This is basically what @Einstein42's new interface file does. It allows existing node server to run on PG3 but doesn't provide any new API's or features for new node servers.

PG2 and PG3 co-existing. Someone had stated that PG3 was Polisy only, meaning the RPi Polyglot was basically stuck at PG2. while the easy solution for Polyglot maintainers is to require different interface modules for each, that may mean having to maintaining two node servers for node server authors. In addition, what's the roadmap look like for PGC? Currently it is supporting the "legacy" API, is that going to change? Will PGC be updated with the same capabilities as PG3 (and have it's interface API synced with the PG3 interface API or not?

Even with the additional complexity of trying to support all that in one interface module, I think it will be worth the additional effort to maintain it, as long as the code is well documented and clear.

Of course, I haven't seen any long term roadmaps for Polyglot from UDI so I may be making invalid assumptions here.

jimboca commented 4 years ago

Yes, agree that this becomes much more difficult/impossible if PG3 is only Polisy, but that's not how I understand it, will need to get official clarification from @mkohanim on what platforms will be supported. But, one of the goals I thought for PG3 was to make as much code as possible common on PGC.

mkohanim commented 4 years ago

Hello all,

PG3 is Polisy and Cloud only. The reason is that it ties into our store and developer program and, therefore, it would be very difficult to manage all differnet platforms (support). For instance, we still get support requests for such things as running Polyglot on NAS, RPI3 vs. RPI4, etc.

With kind regards,

Michel Kohanim CEO

(p) 818.631.0333 http://www.universal-devices.comhttp://www.universal-devices.com/

From: jimboca notifications@github.com Sent: Sunday, August 9, 2020 11:55 AM To: UniversalDevicesInc/pg3-python-interface pg3-python-interface@noreply.github.com Cc: Michel Kohanim michel@universal-devices.com; Mention mention@noreply.github.com Subject: Re: [UniversalDevicesInc/pg3-python-interface] Making node.primary and node.parent consistent (#6)

Yes, agree that this becomes much more difficult/impossible if PG3 is only Polisy, but that's not how I understand it, will need to get official clarification from @mkohanimhttps://github.com/mkohanim on what platforms will be supported. But, one of the goals I thought for PG3 was to make as much code as possible common on PGC.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/UniversalDevicesInc/pg3-python-interface/issues/6#issuecomment-671088246, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ADMVJPLPE5KTJMTYXLWTLO3R73WHHANCNFSM4PVY4VMA.

Goose66 commented 4 years ago

Based on that knowledge, and if monetization of nodeservers for developers is also in the cards, then now would be the time for any breaking changes, and it really doesn't make sense to have any kind of backward compatibility mechanism with v2 nodeservers. Developers will have to make the changes for 3.0 architecture in order to port their nodeservers over to PG3 and participate in the new environment. At the same time, I think it behooves us to make sure that PG3 presents some higher level of robustness and consistency to consumers in presentation and operation of nodes and nodeservers, in order to justify the (potential) cost of moving to PG3. A lot of that can come from restrictions through the Polyglot API.

mkohanim commented 4 years ago

The whole point of PG3 exercise is monetization for developers. We have spent an enormous amount of $$ and resources to get our store (www.universal-devices.comhttp://www.universal-devices.com) hooked up with the Polyglot store, developer accounts, and Paypal. For instance, as a developer, once you publish your node server (you will include the price or if it’s subscription based), first, it’s vet against the developer membership status and, if vetted, it’s published to our store where customers can buy (must have a registered Polisy).

In short, I am 100% with Randy here. If there needs to be breaking changes, now is the time otherwise all our efforts will have been in vain.

With kind regards,

Michel Kohanim CEO

(p) 818.631.0333 http://www.universal-devices.comhttp://www.universal-devices.com/

From: W. Randy King notifications@github.com Sent: Monday, August 10, 2020 6:22 AM To: UniversalDevicesInc/pg3-python-interface pg3-python-interface@noreply.github.com Cc: Michel Kohanim michel@universal-devices.com; Mention mention@noreply.github.com Subject: Re: [UniversalDevicesInc/pg3-python-interface] Making node.primary and node.parent consistent (#6)

Based on that knowledge, and if monetization of nodeservers for developers is also in the cards, then now would be the time for any breaking changes, and it really doesn't make sense to have any kind of backward compatibility mechanism with v2 nodeservers. Developers will have to make the changes for 3.0 architecture in order to port their nodeservers over to PG3 and participate in the new environment. At the same time, I think it behooves us to make sure that PG3 presents some higher level of robustness and consistency to consumers in presentation and operation of nodes and nodeservers, in order to justify the (potential) cost of moving to PG3. A lot of that can come from restrictions through the Polyglot API.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/UniversalDevicesInc/pg3-python-interface/issues/6#issuecomment-671350375, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ADMVJPOGDXITTACKS2IO53DR77X53ANCNFSM4PVY4VMA.

jimboca commented 4 years ago

That will mean all developers will need to start a new repository that is for PG3 only of each nodeserver, otherwise PG2 will think there are new versions when updates are released. We will of course also have users requesting enhancements/fixes to the PG2 so that will be fun...

Goose66 commented 4 years ago

It's going to burn a lot of users for sure. Always does when you move from free to paid. That's why there needs to be a differentiator: something better about PG3 that makes users migrate. If we leave it the same for nodeserver compatibility, then we've lost motivation for users to migrate to the new model. UDI support is one advantage, but there needs to be others. I think some of these probably need enhancements to the ISY Node Server API.

And Polyglot 2 will survive, I assume (nobody's suggesting closing off the Nodeserver API, are they?) and developers can keep rolling out changes/fixes for v2 nodeservers as they see fit. There's also Nodelink.

bpaauwe commented 4 years ago

My whole idea of trying to make one interface module that supported different versions of both node servers and Polyglot was based on the fact that @Einstein42 published this interface module whose sole purpose seemed to be to allow existing node servers to run on PG3. If breaking changes are going to be made, then this interface module probably shouldn't exist.

So before any of us go off and do something that either is a waste of time or takes this in a direction that UDI is not on-board with, we need to get some clear direction from UDI for the future of node servers.

  1. What is the plan for the existing 80+ node servers?
    • Does UDI want these running on PG3 or not?
    • Does UDI plane to provide any support for the PG2 platform going forward?
    • What is the transition plan/timeframe for moving to PG3?
  2. What are the main new features and capabilities we'll get with PG3?
    • From above, we get ability to sell node server and UDI support for PG2 goes away. That's a pretty nice change but....
    • There should be new capabilities that help node server developers (we've made a few suggestions both here and in the past)
    • There should be user visible changes that are compelling to users so they feel it's worth spending money on new node servers.

These aren't things that should be answered here, on this thread, but probably on the Slack channel. This is something I think UDI needs to drive as they are really the authority here. They should be taking our input into account but I think we really need a fairly definitive direction that we'll probably not reach by consensus.

Goose66 commented 4 years ago

@Einstein42 published this interface module whose sole purpose seemed to be to allow existing node servers to run on PG3

AFAIK, this is just the Python nodeserver interface module for PG3 - the same as polyinterface/pgc_interface for Polyglot v2. However, I do hope that there is just the one for PG3 - not separate ones for Cloud or Polisy.

mkohanim commented 4 years ago

Bob, thanks so very much for putting this together. Here are my thoughts:

  1. All node servers in PGC must be migrated to PG3 regardless
  2. All node servers in Polisy must be migrated to PG3 regardless
  3. PG2 can exist and have a life of its own but UD will not support installations on anything but RPi or PGC
  4. UD is willing to pay either a) each developer to migrate to PG3 or b) pay someone who can develop a Python and Node.js migration script (from PG2 to PG3) to help the developers
  5. Enhancements in PG3
    • Security (node servers will run using a different UID than Polyglot)
    • Consistent behavior between PG and PGC especially support for user configuration parameters
    • Tighter integration between ISY Code (not HW) and PG including the C/C++ node server template
    • Support for Strings (in ISY + PG)
    • Support for Streams (planned)
    • There are at least 10 other recommendations in github (and other places) that we will go through and prioritize
  6. The goal is to have PG3 ready for developer testing by the end of the month but I defer to Einstein.42. Once developer testing is done, UD will send an email to request for beta testers. Once that’s done, we go GA

I do not mind having backward compatibility with PG2. The main question is: how difficult is it to maintain such an infrastructure with different protocols?

With kind regards,

Michel Kohanim CEO

(p) 818.631.0333 http://www.universal-devices.comhttp://www.universal-devices.com/

From: Bob Paauwe notifications@github.com Sent: Tuesday, August 11, 2020 9:00 AM To: UniversalDevicesInc/pg3-python-interface pg3-python-interface@noreply.github.com Cc: Michel Kohanim michel@universal-devices.com; Mention mention@noreply.github.com Subject: Re: [UniversalDevicesInc/pg3-python-interface] Making node.primary and node.parent consistent (#6)

My whole idea of trying to make one interface module that supported different versions of both node servers and Polyglot was based on the fact that @Einstein42https://github.com/Einstein42 published this interface module whose sole purpose seemed to be to allow existing node servers to run on PG3. If breaking changes are going to be made, then this interface module probably shouldn't exist.

So before any of us go off and do something that either is a waste of time or takes this in a direction that UDI is not on-board with, we need to get some clear direction from UDI for the future of node servers.

  1. What is the plan for the existing 80+ node servers?
    • Does UDI want these running on PG3 or not?
    • Does UDI plane to provide any support for the PG2 platform going forward?
    • What is the transition plan/timeframe for moving to PG3?
  2. What are the main new features and capabilities we'll get with PG3?
    • From above, we get ability to sell node server and UDI support for PG2 goes away. That's a pretty nice change but....
    • There should be new capabilities that help node server developers (we've made a few suggestions both here and in the past)
    • There should be user visible changes that are compelling to users so they feel it's worth spending money on new node servers.

These aren't things that should be answered here, on this thread, but probably on the Slack channel. This is something I think UDI needs to drive as they are really the authority here. They should be taking our input into account but I think we really need a fairly definitive direction that we'll probably not reach by consensus.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/UniversalDevicesInc/pg3-python-interface/issues/6#issuecomment-672045338, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ADMVJPP3AUMVDPEEJNXKJITSAFTH7ANCNFSM4PVY4VMA.

mkohanim commented 4 years ago

Hi Randy,

This is very true. This said, however, the paid part is 100% up to the developers. i.e. UD is NOT going to force the developers to charge for their node servers. So, the major differentiations for justification for charging customers money should come from the developers themselves. For instance, making it easier for customers to commission is the recurring support tickets we are getting. i.e. rather than asking customers to enter a JSON array, perhaps we should go back to what @firstone suggested a while back and make it consistent across PG3/PGC.

On the UD side:

  1. Security
    • Different UID for node server
    • APIs to use encrypted flash storage for sensitive data (instead of the db). The encryption key is different for each flash
    • Use TPM more effectively
  2. Additional node server APIs for Strings and Streams
  3. Describing user input through node server APIs … i.e. the user has to input something into ISY (or the App on ISY). Without this feature, we cannot have true node servers for Z-Wave/Zigbee etc.
  4. Tighter integration with ISY Code

With kind regards,

Michel Kohanim CEO

(p) 818.631.0333 http://www.universal-devices.comhttp://www.universal-devices.com/

From: W. Randy King notifications@github.com Sent: Tuesday, August 11, 2020 7:01 AM To: UniversalDevicesInc/pg3-python-interface pg3-python-interface@noreply.github.com Cc: Michel Kohanim michel@universal-devices.com; Mention mention@noreply.github.com Subject: Re: [UniversalDevicesInc/pg3-python-interface] Making node.primary and node.parent consistent (#6)

It's going to burn a lot of users for sure. Always does when you move from free to paid. That's why there needs to be a differentiator: something better about PG3 that makes users migrate. If we leave it the same for nodeserver compatibility, then we've lost motivation for users to migrate to the new model. UDI support is one advantage, but there needs to be others. I think some of these probably need enhancements to the ISY Node Server API.

And Polyglot 2 will survive, I assume (nobody's suggesting closing off the Nodeserver API, are they?) and developers can keep rolling out changes/fixes for v2 nodeservers as they see fit. There's also Nodelink.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/UniversalDevicesInc/pg3-python-interface/issues/6#issuecomment-671964914, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ADMVJPMFWESTPUBIXX4MMMTSAFFLDANCNFSM4PVY4VMA.

mkohanim commented 4 years ago

I think so.

With kind regards,

Michel Kohanim CEO

(p) 818.631.0333 http://www.universal-devices.comhttp://www.universal-devices.com/

From: jimboca notifications@github.com Sent: Monday, August 10, 2020 2:23 PM To: UniversalDevicesInc/pg3-python-interface pg3-python-interface@noreply.github.com Cc: Michel Kohanim michel@universal-devices.com; Mention mention@noreply.github.com Subject: Re: [UniversalDevicesInc/pg3-python-interface] Making node.primary and node.parent consistent (#6)

That will mean all developers will need to start a new repository that is for PG3 only of each nodeserver, otherwise PG2 will think there are new versions when updates are released. We will of course also have users requesting enhancements/fixes to the PG2 so that will be fun...

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/UniversalDevicesInc/pg3-python-interface/issues/6#issuecomment-671596600, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ADMVJPL57LE3AVC5TOFRPBDSABQJZANCNFSM4PVY4VMA.

Goose66 commented 4 years ago

There are at least 10 other recommendations in github (and other places) that we will go through and prioritize

I hope timestamp UOM for driver values is one that makes the cut! :)

bpaauwe commented 4 years ago

I think so. From: jimboca notifications@github.com That will mean all developers will need to start a new repository that is for PG3 only of each nodeserver, otherwise PG2 will think there are new versions when updates are released. We will of course also have users requesting enhancements/fixes to the PG2 so that will be fun...

If we're going to need new repositories anyway, is there any thoughts about how we're actually going to protect the node server source? The current method of cloning a github repository leaves the node server open for anyone to clone the authors work and either modify or enhance and re-distribute. I don't really want to put a lot of effort into creating a "paid" node server just to make the source available to anyone with no real restrictions/protections.

While cloning a repository as an install method was a really clever solution, I don't think it's going to work with non-free node servers.

mkohanim commented 4 years ago

That’s an excellent point with one question: even if you don’t clone the git, can’t hackers and geeks just to go to /var/polyglot/nodeservers/x/ and read all the *.py files? So, ignoring the git clone issue, the possible remedies:

  1. Binary (something like Cython)

    • Optional compilation to binary: the developer decides whether or not the node server should be distributed in binary
    • Force everyone to compile into binary Con: compilation might be too difficult when too many python libraries are involved. And, in some cases, it can be reverse engineered

  2. Move everything to C/C++ node servers (Bob is devising it as we speak)

I cannot see any other method for security the source.

With kind regards,

Michel Kohanim CEO

(p) 818.631.0333 http://www.universal-devices.comhttp://www.universal-devices.com/

From: Bob Paauwe notifications@github.com Sent: Tuesday, August 11, 2020 1:18 PM To: UniversalDevicesInc/pg3-python-interface pg3-python-interface@noreply.github.com Cc: Michel Kohanim michel@universal-devices.com; Mention mention@noreply.github.com Subject: Re: [UniversalDevicesInc/pg3-python-interface] Making node.primary and node.parent consistent (#6)

I think so. From: jimboca notifications@github.commailto:notifications@github.com That will mean all developers will need to start a new repository that is for PG3 only of each nodeserver, otherwise PG2 will think there are new versions when updates are released. We will of course also have users requesting enhancements/fixes to the PG2 so that will be fun...

If we're going to need new repositories anyway, is there any thoughts about how we're actually going to protect the node server source? The current method of cloning a github repository leaves the node server open for anyone to clone the authors work and either modify or enhance and re-distribute. I don't really want to put a lot of effort into creating a "paid" node server just to make the source available to anyone with no real restrictions/protections.

While cloning a repository as an install method was a really clever solution, I don't think it's going to work with non-free node servers.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/UniversalDevicesInc/pg3-python-interface/issues/6#issuecomment-672257894, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ADMVJPMJR7SA6NY3HUO77ALSAGRRFANCNFSM4PVY4VMA.

firstone commented 4 years ago

I think it's mostly unachievable to stop people from piratings things when they're determined. As such, I find it sufficient that nobody can run an "official" copy of your paid node server. If someone goes and takes some code and writes a completely different node server using some of that code, I'm fine with that. But if someone decides to create an (almost) full copy of your server, I'm sure we can stop it administratively. Likewise, if someone steals my code of paid node server and runs it locally via RPi, so be it.

As far as compiled code goes, please, look into Go instead of / in addition to C++. Much better bang for the buck.C++ is my current primary language and I would never use it if I didn't have to.

On Tue, Aug 11, 2020 at 4:41 PM Michel Kohanim notifications@github.com wrote:

That’s an excellent point with one question: even if you don’t clone the git, can’t hackers and geeks just to go to /var/polyglot/nodeservers/x/ and read all the *.py files? So, ignoring the git clone issue, the possible remedies:

  1. Binary (something like Cython)

    • Optional compilation to binary: the developer decides whether or not the node server should be distributed in binary
    • Force everyone to compile into binary Con: compilation might be too difficult when too many python libraries are involved. And, in some cases, it can be reverse engineered

  2. Move everything to C/C++ node servers (Bob is devising it as we speak)

I cannot see any other method for security the source.

With kind regards,

Michel Kohanim CEO

(p) 818.631.0333 http://www.universal-devices.comhttp://www.universal-devices.com/

From: Bob Paauwe notifications@github.com Sent: Tuesday, August 11, 2020 1:18 PM To: UniversalDevicesInc/pg3-python-interface < pg3-python-interface@noreply.github.com> Cc: Michel Kohanim michel@universal-devices.com; Mention < mention@noreply.github.com> Subject: Re: [UniversalDevicesInc/pg3-python-interface] Making node.primary and node.parent consistent (#6)

I think so. From: jimboca notifications@github.commailto:notifications@github.com That will mean all developers will need to start a new repository that is for PG3 only of each nodeserver, otherwise PG2 will think there are new versions when updates are released. We will of course also have users requesting enhancements/fixes to the PG2 so that will be fun...

If we're going to need new repositories anyway, is there any thoughts about how we're actually going to protect the node server source? The current method of cloning a github repository leaves the node server open for anyone to clone the authors work and either modify or enhance and re-distribute. I don't really want to put a lot of effort into creating a "paid" node server just to make the source available to anyone with no real restrictions/protections.

While cloning a repository as an install method was a really clever solution, I don't think it's going to work with non-free node servers.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub< https://github.com/UniversalDevicesInc/pg3-python-interface/issues/6#issuecomment-672257894>, or unsubscribe< https://github.com/notifications/unsubscribe-auth/ADMVJPMJR7SA6NY3HUO77ALSAGRRFANCNFSM4PVY4VMA>.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/UniversalDevicesInc/pg3-python-interface/issues/6#issuecomment-672268026, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIMADDWWSCSICJLNY2NJZ3SAGUGBANCNFSM4PVY4VMA .

mkohanim commented 4 years ago

Hi @firstone,

I agree but, regardless, the developers must have a choice of using compiled versions. With regard to Go, if you are willing to create a Go template (just like the Python and Node.js ones), I have no problem supporting it. The only question I have is whether or not you have tried Go on BSD?

With kind regards,

Michel Kohanim CEO

(p) 818.631.0333 http://www.universal-devices.comhttp://www.universal-devices.com/

From: firstone notifications@github.com Sent: Tuesday, August 11, 2020 2:04 PM To: UniversalDevicesInc/pg3-python-interface pg3-python-interface@noreply.github.com Cc: Michel Kohanim michel@universal-devices.com; Mention mention@noreply.github.com Subject: Re: [UniversalDevicesInc/pg3-python-interface] Making node.primary and node.parent consistent (#6)

I think it's mostly unachievable to stop people from piratings things when they're determined. As such, I find it sufficient that nobody can run an "official" copy of your paid node server. If someone goes and takes some code and writes a completely different node server using some of that code, I'm fine with that. But if someone decides to create an (almost) full copy of your server, I'm sure we can stop it administratively. Likewise, if someone steals my code of paid node server and runs it locally via RPi, so be it.

As far as compiled code goes, please, look into Go instead of / in addition to C++. Much better bang for the buck.C++ is my current primary language and I would never use it if I didn't have to.

On Tue, Aug 11, 2020 at 4:41 PM Michel Kohanim notifications@github.com<mailto:notifications@github.com> wrote:

That’s an excellent point with one question: even if you don’t clone the git, can’t hackers and geeks just to go to /var/polyglot/nodeservers/x/ and read all the *.py files? So, ignoring the git clone issue, the possible remedies:

  1. Binary (something like Cython)

    • Optional compilation to binary: the developer decides whether or not the node server should be distributed in binary
    • Force everyone to compile into binary Con: compilation might be too difficult when too many python libraries are involved. And, in some cases, it can be reverse engineered

  2. Move everything to C/C++ node servers (Bob is devising it as we speak)

I cannot see any other method for security the source.

With kind regards,

Michel Kohanim CEO

(p) 818.631.0333 http://www.universal-devices.comhttp://www.universal-devices.com/<http://www.universal-devices.com%3chttp:/www.universal-devices.com/>

From: Bob Paauwe notifications@github.com<mailto:notifications@github.com> Sent: Tuesday, August 11, 2020 1:18 PM To: UniversalDevicesInc/pg3-python-interface < pg3-python-interface@noreply.github.commailto:pg3-python-interface@noreply.github.com> Cc: Michel Kohanim michel@universal-devices.com<mailto:michel@universal-devices.com>; Mention < mention@noreply.github.commailto:mention@noreply.github.com> Subject: Re: [UniversalDevicesInc/pg3-python-interface] Making node.primary and node.parent consistent (#6)

I think so. From: jimboca notifications@github.commailto:notifications@github.com<mailto:notifications@github.com%3cmailto:notifications@github.com> That will mean all developers will need to start a new repository that is for PG3 only of each nodeserver, otherwise PG2 will think there are new versions when updates are released. We will of course also have users requesting enhancements/fixes to the PG2 so that will be fun...

If we're going to need new repositories anyway, is there any thoughts about how we're actually going to protect the node server source? The current method of cloning a github repository leaves the node server open for anyone to clone the authors work and either modify or enhance and re-distribute. I don't really want to put a lot of effort into creating a "paid" node server just to make the source available to anyone with no real restrictions/protections.

While cloning a repository as an install method was a really clever solution, I don't think it's going to work with non-free node servers.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub< https://github.com/UniversalDevicesInc/pg3-python-interface/issues/6#issuecomment-672257894>, or unsubscribe< https://github.com/notifications/unsubscribe-auth/ADMVJPMJR7SA6NY3HUO77ALSAGRRFANCNFSM4PVY4VMA>.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/UniversalDevicesInc/pg3-python-interface/issues/6#issuecomment-672268026, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIMADDWWSCSICJLNY2NJZ3SAGUGBANCNFSM4PVY4VMA .

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/UniversalDevicesInc/pg3-python-interface/issues/6#issuecomment-672278518, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ADMVJPOT5APUXYAHHCETOITSAGW5HANCNFSM4PVY4VMA.

firstone commented 4 years ago

Go has BSD ports. But it's not strictly speaking needed because it's compiled and can be built for BSD architecture on any other machine. So as long as polyglot will allow fetching binary instead of git clone, everything should work.

On Tue, Aug 11, 2020 at 5:11 PM Michel Kohanim notifications@github.com wrote:

Hi @firstone,

I agree but, regardless, the developers must have a choice of using compiled versions. With regard to Go, if you are willing to create a Go template (just like the Python and Node.js ones), I have no problem supporting it. The only question I have is whether or not you have tried Go on BSD?

With kind regards,

Michel Kohanim CEO

(p) 818.631.0333 http://www.universal-devices.comhttp://www.universal-devices.com/

From: firstone notifications@github.com Sent: Tuesday, August 11, 2020 2:04 PM To: UniversalDevicesInc/pg3-python-interface < pg3-python-interface@noreply.github.com> Cc: Michel Kohanim michel@universal-devices.com; Mention < mention@noreply.github.com> Subject: Re: [UniversalDevicesInc/pg3-python-interface] Making node.primary and node.parent consistent (#6)

I think it's mostly unachievable to stop people from piratings things when they're determined. As such, I find it sufficient that nobody can run an "official" copy of your paid node server. If someone goes and takes some code and writes a completely different node server using some of that code, I'm fine with that. But if someone decides to create an (almost) full copy of your server, I'm sure we can stop it administratively. Likewise, if someone steals my code of paid node server and runs it locally via RPi, so be it.

As far as compiled code goes, please, look into Go instead of / in addition to C++. Much better bang for the buck.C++ is my current primary language and I would never use it if I didn't have to.

On Tue, Aug 11, 2020 at 4:41 PM Michel Kohanim <notifications@github.com mailto:notifications@github.com> wrote:

That’s an excellent point with one question: even if you don’t clone the git, can’t hackers and geeks just to go to /var/polyglot/nodeservers/x/ and read all the *.py files? So, ignoring the git clone issue, the possible remedies:

  1. Binary (something like Cython)

    • Optional compilation to binary: the developer decides whether or not the node server should be distributed in binary
    • Force everyone to compile into binary Con: compilation might be too difficult when too many python libraries are involved. And, in some cases, it can be reverse engineered

  2. Move everything to C/C++ node servers (Bob is devising it as we speak)

I cannot see any other method for security the source.

With kind regards,

Michel Kohanim CEO

(p) 818.631.0333 http://www.universal-devices.comhttp://www.universal-devices.com/< http://www.universal-devices.com%3chttp:/www.universal-devices.com/>

From: Bob Paauwe <notifications@github.com<mailto: notifications@github.com>> Sent: Tuesday, August 11, 2020 1:18 PM To: UniversalDevicesInc/pg3-python-interface < pg3-python-interface@noreply.github.com<mailto: pg3-python-interface@noreply.github.com>> Cc: Michel Kohanim <michel@universal-devices.com<mailto: michel@universal-devices.com>>; Mention < mention@noreply.github.commailto:mention@noreply.github.com> Subject: Re: [UniversalDevicesInc/pg3-python-interface] Making node.primary and node.parent consistent (#6)

I think so. From: jimboca notifications@github.com<mailto:notifications@github.com mailto:notifications@github.com%3cmailto:notifications@github.com> That will mean all developers will need to start a new repository that is for PG3 only of each nodeserver, otherwise PG2 will think there are new versions when updates are released. We will of course also have users requesting enhancements/fixes to the PG2 so that will be fun...

If we're going to need new repositories anyway, is there any thoughts about how we're actually going to protect the node server source? The current method of cloning a github repository leaves the node server open for anyone to clone the authors work and either modify or enhance and re-distribute. I don't really want to put a lot of effort into creating a "paid" node server just to make the source available to anyone with no real restrictions/protections.

While cloning a repository as an install method was a really clever solution, I don't think it's going to work with non-free node servers.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<

https://github.com/UniversalDevicesInc/pg3-python-interface/issues/6#issuecomment-672257894>,

or unsubscribe<

https://github.com/notifications/unsubscribe-auth/ADMVJPMJR7SA6NY3HUO77ALSAGRRFANCNFSM4PVY4VMA>.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub < https://github.com/UniversalDevicesInc/pg3-python-interface/issues/6#issuecomment-672268026>,

or unsubscribe < https://github.com/notifications/unsubscribe-auth/AAIMADDWWSCSICJLNY2NJZ3SAGUGBANCNFSM4PVY4VMA>

.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub< https://github.com/UniversalDevicesInc/pg3-python-interface/issues/6#issuecomment-672278518>, or unsubscribe< https://github.com/notifications/unsubscribe-auth/ADMVJPOT5APUXYAHHCETOITSAGW5HANCNFSM4PVY4VMA>.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/UniversalDevicesInc/pg3-python-interface/issues/6#issuecomment-672281465, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIMADB4ULKPGLALDSPHD7DSAGXXDANCNFSM4PVY4VMA .

bpaauwe commented 4 years ago

I think there's a pretty big difference between a system where you have to pay for a product before you can download it and one where the product is available for download and install without paying and leaving it to the honor system to pay for it.

Anyone that is selling node servers as part of their business is not going to want to place their product on a public github for anyone to grab. Even with binary versions, placing the binary on a public github is not going to work.

The node servers really need to be distributed from a secure server. Once the user has paid for and installed, I'm less concerned that they will try to profit from that.

firstone commented 4 years ago

Public or private really doesn't factor into debate. If you have python in source code form even locally, anybody can copy it. Likewise, it's pretty hard to do secure binary distribution. I think the closest thing would be some kind of rights management system that would tie node server X to user account Y, or, probably better, to ISY uuid.

On Tue, Aug 11, 2020 at 5:50 PM Bob Paauwe notifications@github.com wrote:

I think there's a pretty big difference between a system where you have to pay for a product before you can download it and one where the product is available for download and install without paying and leaving it to the honor system to pay for it.

Anyone that is selling node servers as part of their business is not going to want to place their product on a public github for anyone to grab. Even with binary versions, placing the binary on a public github is not going to work.

The node servers really need to be distributed from a secure server. Once the user has paid for and installed, I'm less concerned that they will try to profit from that.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/UniversalDevicesInc/pg3-python-interface/issues/6#issuecomment-672297077, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIMADEPB54HM35YOPUUF3LSAG4LDANCNFSM4PVY4VMA .

Goose66 commented 4 years ago

We need to think about the needs of all of the developers here. I, for one, will never make a "business" out of developing and selling nodeservers. The thing about getting revenue for nodeservers is that it may offset some of my acquisition costs of hardware for my otherwise hobby of home automation. If we move to a model that requires compiled C++ binaries and support contracts and the like for nodeservers, I will likely just stick with Polyglot v2 on my RPi and developing nodeservers for the hardware I own. I may be alone in this, but I believe that becoming too restrictive is going to lose you nodeserver developers.

And while I am all for there being a pay-for-nodeserver-based Polyglot v3 ecosystem for implementing interfaces, if it also means locking other developers out of the ISY Node Server API (or other APIs of the ISY), then you may likely lose me as a user, as well.

mkohanim commented 4 years ago

I very much agree with you. This said, we are not going to lock people out of anything: you can develop any node server, run it on whatever you want, and share it with everyone else you want. This said, we have customers who call us for support on most exotic hardware some of which I had never even heard of. We cannot offer free support to these types of configurations. On the other hand, we do offer extensive support (hand holding/remote session/configuration help) for pretty much anything in the store. Therefore, whatever is deployed on Polisy, will be vetted, tested, supported and thus it’s up to the developer to decide whether or not he/she wants to charge for it.

Furthermore, as we move ISY to Polisy, then having an RPi in addition to Polisy makes a lot less sense.

With kind regards,

Michel Kohanim CEO

(p) 818.631.0333 http://www.universal-devices.comhttp://www.universal-devices.com/

From: W. Randy King notifications@github.com Sent: Tuesday, August 11, 2020 4:05 PM To: UniversalDevicesInc/pg3-python-interface pg3-python-interface@noreply.github.com Cc: Michel Kohanim michel@universal-devices.com; Mention mention@noreply.github.com Subject: Re: [UniversalDevicesInc/pg3-python-interface] Making node.primary and node.parent consistent (#6)

We need to think about the needs of all of the developers here. I, for one, will never make a "business" out of developing and selling nodeservers. The thing about getting revenue for nodeservers is that it may offset some of my acquisition costs of hardware for my otherwise hobby of home automation. If we move to a model that requires compiled C++ binaries and support contracts and the like for nodeservers, I will likely just stick with Polyglot v2 on my RPi and developing nodeservers for the hardware I own. I may be alone in this, but I believe that becoming too restrictive is going to lose you nodeserver developers.

And while I am all for there being a pay-for-nodeserver-based Polyglot v3 ecosystem for implementing interfaces, if it also means locking other developers out of the ISY Node Server API (or other APIs of the ISY), then you may likely lose me as a user, as well.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/UniversalDevicesInc/pg3-python-interface/issues/6#issuecomment-672342177, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ADMVJPNVEHET5IEGHDWZEDDSAHFARANCNFSM4PVY4VMA.

Goose66 commented 4 years ago

I'm onboard with all of that. Let's just keep a modern language like Python or JS in the mix, if possible.

mkohanim commented 4 years ago

Excellent. With regard to datetime uom, it's already there now:

define UD_UOM_DATETIME_NTP 137 // | NTP DateTime - Number of seconds since 1900

With kind regards,

Michel Kohanim CEO

(p) 818.631.0333 http://www.universal-devices.com

From: W. Randy King notifications@github.com Sent: Tuesday, August 11, 2020 4:38:50 PM To: UniversalDevicesInc/pg3-python-interface pg3-python-interface@noreply.github.com Cc: Michel Kohanim michel@universal-devices.com; Mention mention@noreply.github.com Subject: Re: [UniversalDevicesInc/pg3-python-interface] Making node.primary and node.parent consistent (#6)

I'm onboard with all of that. Let's just keep a modern language like Python or JS in the mix, if possible.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/UniversalDevicesInc/pg3-python-interface/issues/6#issuecomment-672365447, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ADMVJPMMJAIMKWKSY64C6XDSAHJAVANCNFSM4PVY4VMA.

mkohanim commented 4 years ago

By the way, here’s a list of all the new UOMs in 5.1.x:

define UD_UOM_MOL_PER_M3 121 // | Mole per cubic meter (mol/m3)

define UD_UOM_MICROGRAM_PER_M3 122 // | Microgram per cubic meter (g/m3)

define UD_UOM_BQ_PER_M3 123 // | Becquerel per cubic meter (bq/m3)

define UD_UOM_PCI_PER_LITER 124 // | Picocuries per liter (pCi/l)

define UD_UOM_PH 125 // | Acidity (pH)

define UD_UOM_BPM 126 // | Beats per Minute (bpm)

define UD_UOM_MM_HG 127 // | Millimeters of mercury (for blood pressure)

define UD_UOM_JOULE 128 // | Joule (J)

define UD_UOM_BMI 129 // | Body Mass Index (BMI)

define UD_UOM_LITER_PER_HOUR 130 // | Liters per hour

define UD_UOM_DECIBEL_MILLIWATTS 131 // | Decibel Milliwatts (dBm)

define UD_UOM_BREATHS_PER_MINUTE 132 // | Breaths per minute

define UD_UOM_KILOHERTZ 133 // | Kilohertz (kHz)

define UD_UOM_METER_PER_SEC2 134 // | Meters per squared Seconds (m/sec2)

define UD_UOM_VOLT_AMP 135 // | For Apparent Power, VA = Volt-Amp

define UD_UOM_VOLT_AMP_REACTIVE 136 // | For Reactive Power, VAR = Volt-Amp Reactive

define UD_UOM_DATETIME_NTP 137 // | NTP DateTime - Number of seconds since 1900

define UD_UOM_PSI 138 // | Pound per square inch (PSI)

define UD_UOM_DIRECTION 139 // | 0 to 360 degrees

define UD_UOM_MILLIGRAM_PER_LITER 140 // | Milligram per liter (mg/l)

define UD_UOM_NEWTON 141 // | Newton (N)

And another feature we are working on is Dynamic UOM.

With kind regards,

Michel Kohanim CEO

(p) 818.631.0333 http://www.universal-devices.comhttp://www.universal-devices.com/

From: W. Randy King notifications@github.com Sent: Tuesday, August 11, 2020 1:04 PM To: UniversalDevicesInc/pg3-python-interface pg3-python-interface@noreply.github.com Cc: Michel Kohanim michel@universal-devices.com; Mention mention@noreply.github.com Subject: Re: [UniversalDevicesInc/pg3-python-interface] Making node.primary and node.parent consistent (#6)

There are at least 10 other recommendations in github (and other places) that we will go through and prioritize

I hope timestamp UOM for driver values is one that makes the cut! :)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/UniversalDevicesInc/pg3-python-interface/issues/6#issuecomment-672249811, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ADMVJPP2SRWJ4MG5DEV2553SAGPZZANCNFSM4PVY4VMA.

mkohanim commented 4 years ago

@firstone, will you be making a Go Node Server template?

With kind regards,

Michel Kohanim CEO

(p) 818.631.0333 http://www.universal-devices.comhttp://www.universal-devices.com/

From: firstone notifications@github.com Sent: Tuesday, August 11, 2020 2:28 PM To: UniversalDevicesInc/pg3-python-interface pg3-python-interface@noreply.github.com Cc: Michel Kohanim michel@universal-devices.com; Mention mention@noreply.github.com Subject: Re: [UniversalDevicesInc/pg3-python-interface] Making node.primary and node.parent consistent (#6)

Go has BSD ports. But it's not strictly speaking needed because it's compiled and can be built for BSD architecture on any other machine. So as long as polyglot will allow fetching binary instead of git clone, everything should work.

On Tue, Aug 11, 2020 at 5:11 PM Michel Kohanim notifications@github.com<mailto:notifications@github.com> wrote:

Hi @firstone,

I agree but, regardless, the developers must have a choice of using compiled versions. With regard to Go, if you are willing to create a Go template (just like the Python and Node.js ones), I have no problem supporting it. The only question I have is whether or not you have tried Go on BSD?

With kind regards,

Michel Kohanim CEO

(p) 818.631.0333 http://www.universal-devices.comhttp://www.universal-devices.com/<http://www.universal-devices.com%3chttp:/www.universal-devices.com/>

From: firstone notifications@github.com<mailto:notifications@github.com> Sent: Tuesday, August 11, 2020 2:04 PM To: UniversalDevicesInc/pg3-python-interface < pg3-python-interface@noreply.github.commailto:pg3-python-interface@noreply.github.com> Cc: Michel Kohanim michel@universal-devices.com<mailto:michel@universal-devices.com>; Mention < mention@noreply.github.commailto:mention@noreply.github.com> Subject: Re: [UniversalDevicesInc/pg3-python-interface] Making node.primary and node.parent consistent (#6)

I think it's mostly unachievable to stop people from piratings things when they're determined. As such, I find it sufficient that nobody can run an "official" copy of your paid node server. If someone goes and takes some code and writes a completely different node server using some of that code, I'm fine with that. But if someone decides to create an (almost) full copy of your server, I'm sure we can stop it administratively. Likewise, if someone steals my code of paid node server and runs it locally via RPi, so be it.

As far as compiled code goes, please, look into Go instead of / in addition to C++. Much better bang for the buck.C++ is my current primary language and I would never use it if I didn't have to.

On Tue, Aug 11, 2020 at 4:41 PM Michel Kohanim <notifications@github.com mailto:notifications@github.com%0b> mailto:notifications@github.com> wrote:

That’s an excellent point with one question: even if you don’t clone the git, can’t hackers and geeks just to go to /var/polyglot/nodeservers/x/ and read all the *.py files? So, ignoring the git clone issue, the possible remedies:

  1. Binary (something like Cython)

    • Optional compilation to binary: the developer decides whether or not the node server should be distributed in binary
    • Force everyone to compile into binary Con: compilation might be too difficult when too many python libraries are involved. And, in some cases, it can be reverse engineered

  2. Move everything to C/C++ node servers (Bob is devising it as we speak)

I cannot see any other method for security the source.

With kind regards,

Michel Kohanim CEO

(p) 818.631.0333 http://www.universal-devices.comhttp://www.universal-devices.com/<<http://www.universal-devices.com%3chttp:/www.universal-devices.com/%3c http://www.universal-devices.com%3chttp:/www.universal-devices.com/>>

From: Bob Paauwe <notifications@github.com<mailto: mailto:notifications@github.com%3cmailto:%0b> notifications@github.commailto:notifications@github.com>> Sent: Tuesday, August 11, 2020 1:18 PM To: UniversalDevicesInc/pg3-python-interface < pg3-python-interface@noreply.github.commailto<mailto:pg3-python-interface@noreply.github.com%3cmailto: pg3-python-interface@noreply.github.commailto:pg3-python-interface@noreply.github.com>> Cc: Michel Kohanim <michel@universal-devices.com<mailto: mailto:michel@universal-devices.com%3cmailto:%0b> michel@universal-devices.commailto:michel@universal-devices.com>>; Mention < mention@noreply.github.commailto:mention@noreply.github.com<mailto:mention@noreply.github.com%3cmailto:mention@noreply.github.com>> Subject: Re: [UniversalDevicesInc/pg3-python-interface] Making node.primary and node.parent consistent (#6)

I think so. From: jimboca notifications@github.commailto:notifications@github.com<mailto:notifications@github.com%3cmailto:notifications@github.com mailto:notifications@github.com%3cmailto:notifications@github.com> That will mean all developers will need to start a new repository that is for PG3 only of each nodeserver, otherwise PG2 will think there are new versions when updates are released. We will of course also have users requesting enhancements/fixes to the PG2 so that will be fun...

If we're going to need new repositories anyway, is there any thoughts about how we're actually going to protect the node server source? The current method of cloning a github repository leaves the node server open for anyone to clone the authors work and either modify or enhance and re-distribute. I don't really want to put a lot of effort into creating a "paid" node server just to make the source available to anyone with no real restrictions/protections.

While cloning a repository as an install method was a really clever solution, I don't think it's going to work with non-free node servers.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<

https://github.com/UniversalDevicesInc/pg3-python-interface/issues/6#issuecomment-672257894>,

or unsubscribe<

https://github.com/notifications/unsubscribe-auth/ADMVJPMJR7SA6NY3HUO77ALSAGRRFANCNFSM4PVY4VMA>.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub < https://github.com/UniversalDevicesInc/pg3-python-interface/issues/6#issuecomment-672268026>,

or unsubscribe < https://github.com/notifications/unsubscribe-auth/AAIMADDWWSCSICJLNY2NJZ3SAGUGBANCNFSM4PVY4VMA>

.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub< https://github.com/UniversalDevicesInc/pg3-python-interface/issues/6#issuecomment-672278518>, or unsubscribe< https://github.com/notifications/unsubscribe-auth/ADMVJPOT5APUXYAHHCETOITSAGW5HANCNFSM4PVY4VMA>.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/UniversalDevicesInc/pg3-python-interface/issues/6#issuecomment-672281465, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIMADB4ULKPGLALDSPHD7DSAGXXDANCNFSM4PVY4VMA .

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/UniversalDevicesInc/pg3-python-interface/issues/6#issuecomment-672288663, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ADMVJPM67FIIIH5JO7LTCIDSAGZWPANCNFSM4PVY4VMA.

mkohanim commented 4 years ago

@firstone, node server purchase + Polisy ID + payment + userid + developer id linkages are already there. Also, refunds will automatically remove the node server from Polyglot.

With kind regards,

Michel Kohanim CEO

(p) 818.631.0333 http://www.universal-devices.comhttp://www.universal-devices.com/

From: firstone notifications@github.com Sent: Tuesday, August 11, 2020 3:08 PM To: UniversalDevicesInc/pg3-python-interface pg3-python-interface@noreply.github.com Cc: Michel Kohanim michel@universal-devices.com; Mention mention@noreply.github.com Subject: Re: [UniversalDevicesInc/pg3-python-interface] Making node.primary and node.parent consistent (#6)

Public or private really doesn't factor into debate. If you have python in source code form even locally, anybody can copy it. Likewise, it's pretty hard to do secure binary distribution. I think the closest thing would be some kind of rights management system that would tie node server X to user account Y, or, probably better, to ISY uuid.

On Tue, Aug 11, 2020 at 5:50 PM Bob Paauwe notifications@github.com<mailto:notifications@github.com> wrote:

I think there's a pretty big difference between a system where you have to pay for a product before you can download it and one where the product is available for download and install without paying and leaving it to the honor system to pay for it.

Anyone that is selling node servers as part of their business is not going to want to place their product on a public github for anyone to grab. Even with binary versions, placing the binary on a public github is not going to work.

The node servers really need to be distributed from a secure server. Once the user has paid for and installed, I'm less concerned that they will try to profit from that.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/UniversalDevicesInc/pg3-python-interface/issues/6#issuecomment-672297077, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIMADEPB54HM35YOPUUF3LSAG4LDANCNFSM4PVY4VMA .

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/UniversalDevicesInc/pg3-python-interface/issues/6#issuecomment-672308010, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ADMVJPIZR6FU5JRBQCGLFVDSAG6KTANCNFSM4PVY4VMA.

mkohanim commented 4 years ago

@Bob,

Would a private git repository work for you? My main concern with private repository is managing ssh keys in each Polisy.

With kind regards,

Michel Kohanim CEO

(p) 818.631.0333 http://www.universal-devices.comhttp://www.universal-devices.com/

From: Bob Paauwe notifications@github.com Sent: Tuesday, August 11, 2020 2:51 PM To: UniversalDevicesInc/pg3-python-interface pg3-python-interface@noreply.github.com Cc: Michel Kohanim michel@universal-devices.com; Mention mention@noreply.github.com Subject: Re: [UniversalDevicesInc/pg3-python-interface] Making node.primary and node.parent consistent (#6)

I think there's a pretty big difference between a system where you have to pay for a product before you can download it and one where the product is available for download and install without paying and leaving it to the honor system to pay for it.

Anyone that is selling node servers as part of their business is not going to want to place their product on a public github for anyone to grab. Even with binary versions, placing the binary on a public github is not going to work.

The node servers really need to be distributed from a secure server. Once the user has paid for and installed, I'm less concerned that they will try to profit from that.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/UniversalDevicesInc/pg3-python-interface/issues/6#issuecomment-672297077, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ADMVJPL5VF7DJTG67ZRQVXTSAG4LDANCNFSM4PVY4VMA.

firstone commented 4 years ago

I can do it if there's interest. I was just suggesting because we were talking about compiled languages and Go is more in spirit with dynamically typed languages and garbage collection than c++.

On Wed, Aug 12, 2020 at 10:50 AM Michel Kohanim notifications@github.com wrote:

@firstone, will you be making a Go Node Server template?

With kind regards,

Michel Kohanim CEO

(p) 818.631.0333 http://www.universal-devices.comhttp://www.universal-devices.com/

From: firstone notifications@github.com Sent: Tuesday, August 11, 2020 2:28 PM To: UniversalDevicesInc/pg3-python-interface < pg3-python-interface@noreply.github.com> Cc: Michel Kohanim michel@universal-devices.com; Mention < mention@noreply.github.com> Subject: Re: [UniversalDevicesInc/pg3-python-interface] Making node.primary and node.parent consistent (#6)

Go has BSD ports. But it's not strictly speaking needed because it's compiled and can be built for BSD architecture on any other machine. So as long as polyglot will allow fetching binary instead of git clone, everything should work.

On Tue, Aug 11, 2020 at 5:11 PM Michel Kohanim <notifications@github.com mailto:notifications@github.com> wrote:

Hi @firstone,

I agree but, regardless, the developers must have a choice of using compiled versions. With regard to Go, if you are willing to create a Go template (just like the Python and Node.js ones), I have no problem supporting it. The only question I have is whether or not you have tried Go on BSD?

With kind regards,

Michel Kohanim CEO

(p) 818.631.0333 http://www.universal-devices.comhttp://www.universal-devices.com/< http://www.universal-devices.com%3chttp:/www.universal-devices.com/>

From: firstone notifications@github.com<mailto:notifications@github.com>

Sent: Tuesday, August 11, 2020 2:04 PM To: UniversalDevicesInc/pg3-python-interface < pg3-python-interface@noreply.github.com<mailto: pg3-python-interface@noreply.github.com>> Cc: Michel Kohanim <michel@universal-devices.com<mailto: michel@universal-devices.com>>; Mention < mention@noreply.github.commailto:mention@noreply.github.com> Subject: Re: [UniversalDevicesInc/pg3-python-interface] Making node.primary and node.parent consistent (#6)

I think it's mostly unachievable to stop people from piratings things when they're determined. As such, I find it sufficient that nobody can run an "official" copy of your paid node server. If someone goes and takes some code and writes a completely different node server using some of that code, I'm fine with that. But if someone decides to create an (almost) full copy of your server, I'm sure we can stop it administratively. Likewise, if someone steals my code of paid node server and runs it locally via RPi, so be it.

As far as compiled code goes, please, look into Go instead of / in addition to C++. Much better bang for the buck.C++ is my current primary language and I would never use it if I didn't have to.

On Tue, Aug 11, 2020 at 4:41 PM Michel Kohanim <notifications@github.com mailto:notifications@github.com%0b> mailto:notifications@github.com> wrote:

That’s an excellent point with one question: even if you don’t clone the git, can’t hackers and geeks just to go to /var/polyglot/nodeservers/x/ and read all the *.py files? So, ignoring the git clone issue, the possible remedies:

  1. Binary (something like Cython)

    • Optional compilation to binary: the developer decides whether or not the node server should be distributed in binary
    • Force everyone to compile into binary Con: compilation might be too difficult when too many python libraries are involved. And, in some cases, it can be reverse engineered

  2. Move everything to C/C++ node servers (Bob is devising it as we speak)

I cannot see any other method for security the source.

With kind regards,

Michel Kohanim CEO

(p) 818.631.0333 http://www.universal-devices.comhttp://www.universal-devices.com/<< http://www.universal-devices.com%3chttp:/www.universal-devices.com/%3c http://www.universal-devices.com%3chttp:/www.universal-devices.com/>>

From: Bob Paauwe <notifications@github.com<mailto: mailto:notifications@github.com%3cmailto:%0b> notifications@github.com mailto:notifications@github.com>> Sent: Tuesday, August 11, 2020 1:18 PM To: UniversalDevicesInc/pg3-python-interface < pg3-python-interface@noreply.github.com<mailto<mailto: pg3-python-interface@noreply.github.com%3cmailto>: pg3-python-interface@noreply.github.com<mailto: pg3-python-interface@noreply.github.com>>> Cc: Michel Kohanim <michel@universal-devices.com<mailto: mailto:michel@universal-devices.com%3cmailto:%0b> michel@universal-devices.commailto:michel@universal-devices.com>>; Mention < mention@noreply.github.com<mailto:mention@noreply.github.com<mailto: mention@noreply.github.com%3cmailto:mention@noreply.github.com>>> Subject: Re: [UniversalDevicesInc/pg3-python-interface] Making node.primary and node.parent consistent (#6)

I think so. From: jimboca notifications@github.com<mailto:notifications@github.com mailto:notifications@github.com%3cmailto:notifications@github.com mailto:notifications@github.com%3cmailto:notifications@github.com> That will mean all developers will need to start a new repository that is for PG3 only of each nodeserver, otherwise PG2 will think there are new versions when updates are released. We will of course also have users requesting enhancements/fixes to the PG2 so that will be fun...

If we're going to need new repositories anyway, is there any thoughts about how we're actually going to protect the node server source? The current method of cloning a github repository leaves the node server open for anyone to clone the authors work and either modify or enhance and re-distribute. I don't really want to put a lot of effort into creating a "paid" node server just to make the source available to anyone with no real restrictions/protections.

While cloning a repository as an install method was a really clever solution, I don't think it's going to work with non-free node servers.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<

https://github.com/UniversalDevicesInc/pg3-python-interface/issues/6#issuecomment-672257894>,

or unsubscribe<

https://github.com/notifications/unsubscribe-auth/ADMVJPMJR7SA6NY3HUO77ALSAGRRFANCNFSM4PVY4VMA>.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <

https://github.com/UniversalDevicesInc/pg3-python-interface/issues/6#issuecomment-672268026>,

or unsubscribe <

https://github.com/notifications/unsubscribe-auth/AAIMADDWWSCSICJLNY2NJZ3SAGUGBANCNFSM4PVY4VMA>

.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<

https://github.com/UniversalDevicesInc/pg3-python-interface/issues/6#issuecomment-672278518>,

or unsubscribe<

https://github.com/notifications/unsubscribe-auth/ADMVJPOT5APUXYAHHCETOITSAGW5HANCNFSM4PVY4VMA>.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub < https://github.com/UniversalDevicesInc/pg3-python-interface/issues/6#issuecomment-672281465>,

or unsubscribe < https://github.com/notifications/unsubscribe-auth/AAIMADB4ULKPGLALDSPHD7DSAGXXDANCNFSM4PVY4VMA>

.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub< https://github.com/UniversalDevicesInc/pg3-python-interface/issues/6#issuecomment-672288663>, or unsubscribe< https://github.com/notifications/unsubscribe-auth/ADMVJPM67FIIIH5JO7LTCIDSAGZWPANCNFSM4PVY4VMA>.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/UniversalDevicesInc/pg3-python-interface/issues/6#issuecomment-672919177, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIMADAQJ7UKZVOBYNACHMTSAKT4ZANCNFSM4PVY4VMA .

firstone commented 4 years ago

Do you somehow identify the node server on the ISY side during verification? In other words, can one take a free node server, plug info into "for pay" node server and use it for free?

On Wed, Aug 12, 2020 at 10:53 AM Michel Kohanim notifications@github.com wrote:

@firstone, node server purchase + Polisy ID + payment + userid + developer id linkages are already there. Also, refunds will automatically remove the node server from Polyglot.

With kind regards,

Michel Kohanim CEO

(p) 818.631.0333 http://www.universal-devices.comhttp://www.universal-devices.com/

From: firstone notifications@github.com Sent: Tuesday, August 11, 2020 3:08 PM To: UniversalDevicesInc/pg3-python-interface < pg3-python-interface@noreply.github.com> Cc: Michel Kohanim michel@universal-devices.com; Mention < mention@noreply.github.com> Subject: Re: [UniversalDevicesInc/pg3-python-interface] Making node.primary and node.parent consistent (#6)

Public or private really doesn't factor into debate. If you have python in source code form even locally, anybody can copy it. Likewise, it's pretty hard to do secure binary distribution. I think the closest thing would be some kind of rights management system that would tie node server X to user account Y, or, probably better, to ISY uuid.

On Tue, Aug 11, 2020 at 5:50 PM Bob Paauwe <notifications@github.com mailto:notifications@github.com> wrote:

I think there's a pretty big difference between a system where you have to pay for a product before you can download it and one where the product is available for download and install without paying and leaving it to the honor system to pay for it.

Anyone that is selling node servers as part of their business is not going to want to place their product on a public github for anyone to grab. Even with binary versions, placing the binary on a public github is not going to work.

The node servers really need to be distributed from a secure server. Once the user has paid for and installed, I'm less concerned that they will try to profit from that.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub < https://github.com/UniversalDevicesInc/pg3-python-interface/issues/6#issuecomment-672297077>,

or unsubscribe < https://github.com/notifications/unsubscribe-auth/AAIMADEPB54HM35YOPUUF3LSAG4LDANCNFSM4PVY4VMA>

.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub< https://github.com/UniversalDevicesInc/pg3-python-interface/issues/6#issuecomment-672308010>, or unsubscribe< https://github.com/notifications/unsubscribe-auth/ADMVJPIZR6FU5JRBQCGLFVDSAG6KTANCNFSM4PVY4VMA>.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/UniversalDevicesInc/pg3-python-interface/issues/6#issuecomment-672921149, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIMADF33GD3LQ6ZEDWDKNTSAKUH7ANCNFSM4PVY4VMA .

mkohanim commented 4 years ago

@firstone,

In the official build (not when developers clone repositories), node servers can only be installed if and only if:

  1. The customer has logged in to our website
  2. He/She has a Polisy registered (just like when you buy modules for ISY)
  3. The node server developer is still a member (otherwise, it would be very difficult for us to contact him/her in case of things we cannot solve)

All the above is already there and waiting for PG3 so that we can test.

With kind regards,

Michel Kohanim CEO

(p) 818.631.0333 http://www.universal-devices.comhttp://www.universal-devices.com/

From: firstone notifications@github.com Sent: Wednesday, August 12, 2020 8:22 AM To: UniversalDevicesInc/pg3-python-interface pg3-python-interface@noreply.github.com Cc: Michel Kohanim michel@universal-devices.com; Mention mention@noreply.github.com Subject: Re: [UniversalDevicesInc/pg3-python-interface] Making node.primary and node.parent consistent (#6)

Do you somehow identify the node server on the ISY side during verification? In other words, can one take a free node server, plug info into "for pay" node server and use it for free?

On Wed, Aug 12, 2020 at 10:53 AM Michel Kohanim notifications@github.com<mailto:notifications@github.com> wrote:

@firstone, node server purchase + Polisy ID + payment + userid + developer id linkages are already there. Also, refunds will automatically remove the node server from Polyglot.

With kind regards,

Michel Kohanim CEO

(p) 818.631.0333 http://www.universal-devices.comhttp://www.universal-devices.com/<http://www.universal-devices.com%3chttp:/www.universal-devices.com/>

From: firstone notifications@github.com<mailto:notifications@github.com> Sent: Tuesday, August 11, 2020 3:08 PM To: UniversalDevicesInc/pg3-python-interface < pg3-python-interface@noreply.github.commailto:pg3-python-interface@noreply.github.com> Cc: Michel Kohanim michel@universal-devices.com<mailto:michel@universal-devices.com>; Mention < mention@noreply.github.commailto:mention@noreply.github.com> Subject: Re: [UniversalDevicesInc/pg3-python-interface] Making node.primary and node.parent consistent (#6)

Public or private really doesn't factor into debate. If you have python in source code form even locally, anybody can copy it. Likewise, it's pretty hard to do secure binary distribution. I think the closest thing would be some kind of rights management system that would tie node server X to user account Y, or, probably better, to ISY uuid.

On Tue, Aug 11, 2020 at 5:50 PM Bob Paauwe <notifications@github.com mailto:notifications@github.com%0b> mailto:notifications@github.com> wrote:

I think there's a pretty big difference between a system where you have to pay for a product before you can download it and one where the product is available for download and install without paying and leaving it to the honor system to pay for it.

Anyone that is selling node servers as part of their business is not going to want to place their product on a public github for anyone to grab. Even with binary versions, placing the binary on a public github is not going to work.

The node servers really need to be distributed from a secure server. Once the user has paid for and installed, I'm less concerned that they will try to profit from that.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub < https://github.com/UniversalDevicesInc/pg3-python-interface/issues/6#issuecomment-672297077>,

or unsubscribe < https://github.com/notifications/unsubscribe-auth/AAIMADEPB54HM35YOPUUF3LSAG4LDANCNFSM4PVY4VMA>

.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub< https://github.com/UniversalDevicesInc/pg3-python-interface/issues/6#issuecomment-672308010>, or unsubscribe< https://github.com/notifications/unsubscribe-auth/ADMVJPIZR6FU5JRBQCGLFVDSAG6KTANCNFSM4PVY4VMA>.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/UniversalDevicesInc/pg3-python-interface/issues/6#issuecomment-672921149, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIMADF33GD3LQ6ZEDWDKNTSAKUH7ANCNFSM4PVY4VMA .

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/UniversalDevicesInc/pg3-python-interface/issues/6#issuecomment-672939987, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ADMVJPKGZUAZTTIG3NU4LLLSAKXSXANCNFSM4PVY4VMA.

bpaauwe commented 4 years ago

@bob, Would a private git repository work for you? My main concern with private repository is managing ssh keys in each Polisy. With kind regards, ** Michel Kohanim CEO (p) 818.631.0333 http://www.universal-devices.comhttp://www.universal-devices.com/ **

Yes, I think so. If there's one github account that contains all the node servers, then the Polisy only needs one key to access that account. Each developer may need to maintain a key so that they can push changes, but that should be pretty easy to manage.

However, while I think using git is a clever solution, there are problems with it. For one, it is easy to break by making updates to the repository that cause the git pull command to fail. There's been support issues because of this where the only current solution is to delete/uninstall the node server and then re-install to get the latest version. It makes creating dynamic node definitions more difficult as local changes to any files in the repository will also break the git pull.

Currently, everyone (I think) uses there node server git repository as both a development repository and a release repository. Maybe that needs to change and the 'release' repository only contains the actual release with no development history. That might start to solve some of the issues. The release repository could then have a defined structure so that the installation code knows what to expect.

I seem to keep rambling about various implementation ideas which is starting to make me wonder if there's a defined design and implementation plan for PG3.

Can we get more details on:

  1. Enhancements in PG3
    • Security (node servers will run using a different UID than Polyglot)
    • Consistent behavior between PG and PGC especially support for user configuration parameters
    • Tighter integration between ISY Code (not HW) and PG including the C/C++ node server template
    • Support for Strings (in ISY + PG)
    • Support for Streams (planned)
    • There are at least 10 other recommendations in github (and other places) that we will go through and prioritize
      1. The goal is to have PG3 ready for developer testing by the end of the month but I defer to Einstein.42. Once developer testing is done,
  2. Describing user input through node server APIs … i.e. the user has to input something into ISY (or the App on ISY). Without this feature, we cannot have true node servers for Z-Wave/Zigbee etc.
  3. Tighter integration with ISY Code

The end of the month isn't that far away and things like support for strings, support for streams and at least 10 other recommendations seem like they could have a pretty big impact on our node server designs. Having a better description of the various enhancements and the timeline for them. Also, what is the timeline for the new PG3 based PGC release?

The above list looks like it would allow us to make much improved node server and I'm really excited to start, but the PG3 interface module release didn't have any of this, it seemed to only exist to support some of the backend changes and doesn't give us any new API features to play with.

mkohanim commented 4 years ago

Hi Bob,

Just to recap, we should use git only for development and then publish to another private non-git based repository. If so, do you have any in mind?

With regard to more details:

  1. Although you don’t see it in the APIs yet, the 2nd major reason for PG3 was to normalize the APIs between PG3 and PGC. So, it will be there. But, before we can go to PGC3, developers – such as yourself – should test PG3 and provide as much feedback as possible
  2. With PG3, node servers use their own UIDs (not Polyglot’s)
  3. Integration with ISY/PG3 is based on what you are doing with C/C++ node server template
  4. Support for Strings/Streams is on the roadmap for ISY 5.2. Z-Wave+ certification is almost done so this is next. The same goes for User Input … i.e. you install a node server that requires user action/input on ISY

With kind regards,

Michel Kohanim CEO

(p) 818.631.0333 http://www.universal-devices.comhttp://www.universal-devices.com/

From: Bob Paauwe notifications@github.com Sent: Friday, August 14, 2020 12:58 PM To: UniversalDevicesInc/pg3-python-interface pg3-python-interface@noreply.github.com Cc: Michel Kohanim michel@universal-devices.com; Mention mention@noreply.github.com Subject: Re: [UniversalDevicesInc/pg3-python-interface] Making node.primary and node.parent consistent (#6)

@bobhttps://github.com/bob, Would a private git repository work for you? My main concern with private repository is managing ssh keys in each Polisy. With kind regards, ** Michel Kohanim CEO (p) 818.631.0333 http://www.universal-devices.comhttp://www.universal-devices.com/ **

Yes, I think so. If there's one github account that contains all the node servers, then the Polisy only needs one key to access that account. Each developer may need to maintain a key so that they can push changes, but that should be pretty easy to manage.

However, while I think using git is a clever solution, there are problems with it. For one, it is easy to break by making updates to the repository that cause the git pull command to fail. There's been support issues because of this where the only current solution is to delete/uninstall the node server and then re-install to get the latest version. It makes creating dynamic node definitions more difficult as local changes to any files in the repository will also break the git pull.

Currently, everyone (I think) uses there node server git repository as both a development repository and a release repository. Maybe that needs to change and the 'release' repository only contains the actual release with no development history. That might start to solve some of the issues. The release repository could then have a defined structure so that the installation code knows what to expect.

I seem to keep rambling about various implementation ideas which is starting to make me wonder if there's a defined design and implementation plan for PG3.

Can we get more details on:

  1. Enhancements in PG3

    • Security (node servers will run using a different UID than Polyglot)
    • Consistent behavior between PG and PGC especially support for user configuration parameters
    • Tighter integration between ISY Code (not HW) and PG including the C/C++ node server template
    • Support for Strings (in ISY + PG)
    • Support for Streams (planned)
    • There are at least 10 other recommendations in github (and other places) that we will go through and prioritize

  2. The goal is to have PG3 ready for developer testing by the end of the month but I defer to Einstein.42. Once developer testing is done,

  3. Describing user input through node server APIs … i.e. the user has to input something into ISY (or the App on ISY). Without this feature, we cannot have true node servers for Z-Wave/Zigbee etc.

  4. Tighter integration with ISY Code

The end of the month isn't that far away and things like support for strings, support for streams and at least 10 other recommendations seem like they could have a pretty big impact on our node server designs. Having a better description of the various enhancements and the timeline for them. Also, what is the timeline for the new PG3 based PGC release?

The above list looks like it would allow us to make much improved node server and I'm really excited to start, but the PG3 interface module release didn't have any of this, it seemed to only exist to support some of the backend changes and doesn't give us any new API features to play with.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/UniversalDevicesInc/pg3-python-interface/issues/6#issuecomment-674248076, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ADMVJPLGCBEA5R5SRC4RUH3SAWJL5ANCNFSM4PVY4VMA.