Dumb Patenting Question

[lrose]

@PRAMANJ

My point is, the SDK does not provide a sand boxed environment for module development with a handful of well planned and documented API's such as the Scripting library does.

The API's may not be as well documented as the Scripting library, but you can set up a gateway as a development environment for new modules, free of charge. So there is a "sand boxed environment".

@PRAMANJ

Even if the Scripting library was converted to a JAVA callable function library I think we would been happier, safer at the same time would have been able to develop our modules faster, version agnostic, more efficient (than scripts) and secure (from IP protection point of view which is the main topic of this discussion).

I disagree.

1. You can call many JAVA functions from scripting already, which is why IA went with Jython as opposed to a pure Python implementation.
2. I don't believe that module development would have been any faster or safer is we could write pure Java code in the designer.
3. Exposing the JAVA classes to the scripting environment would IMO be less secure, and provide less protection for IP than it already does.

[brandon1]

@PGriffith

and 8.3.0 won't be released any earlier than the end of this year

Does this mean we will not have a beta version in the summer to work on porting modules to?

[Kevin.Herron]

There will probably be a beta around the time of ICC (September).

[PRAMANJ]

@lrose

You can call many JAVA functions from scripting already, which is why IA went with Jython as opposed to a pure Python implementation.

I understand that, but I wanted to be able to call the jython scripting library functions from Ignition modules in JAVA as these are easier to learn and use compared to the whole gateway or client or common APIs. After all these jython libraries are written in JAVA itself under the hood. That way our exposure to Ignition SDK APIs would have been reduced.

@lrose

Exposing the JAVA classes to the scripting environment would IMO be less secure, and provide less protection for IP than it already does.

That is not what I want, its the opposite, calling jython functions from JAVA modules so that we use a subset of the Ignition class libraries.

Just a thought , I may be wrong.

[pturmel]

Very difficult to call system.* functions from java directly, as their function signatures are tailored to jython, and the classloaders they originate in are obscured, in many cases, by the ScriptModule infrastructure.

Simply not practical.

[PRAMANJ]

OK got it. Thanks.

But this is the kind of wrapper I was looking for so that our module development can be done with a smaller set of APIs for various group of functions like database manipulation, tag library, networks library, etc as defined in the scripting documentation. Some more functions could have been added to meet any specific requirements of module creation such as signing etc.

This wrapper would have enabled us to build modules easier was my primary objective of this discussion.

What we can achieve with scripts would have become more efficient with its compiled JAVA version, at the same time protected from IP. We could have adopted a cyclic loop of prototyping with scripts and release its compiled JAVA version as a module.

[PRAMANJ]

At least the gateway scoped scripting functions could have been made available so that we could write gateway scopes modules using them in JAVA and deployed them as regular Ignition modules commercially.

[bmusson]

Somewhat relevant xkcd.