Plugin Compiler Optimization

[SBarnes]

Hi Ryan,
I agree with you on "bespoke work" i.e. the client has paid for it and it usually doesn't have further commercial value except as the one off but we have some pieces that do have "generic commercial value" and need some sort of way of protecting this.

[pricerc]

Hi Ryan,
I agree with you on "bespoke work" i.e. the client has paid for it and it usually doesn't have further commercial value except as the one off but we have some pieces that do have "generic commercial value" and need some sort of way of protecting this.

I suppose in the interim, you can use embedded assemblies with the plugin just providing a 'shim' into your code?

Actually, that also raises the issue of code-tampering. There's the aspect of protecting code because of its commercial value. But you could also argue for protecting code from tampering (whether benign or malicious). I know you can sign PowerShell scripts (and they then get a signature block appended as a comment); something similar for plugins could be quite handy. Even if the signature is not visible in the code editor itself. If there was some way of signing, say, the XML I export from my development environment, then if a customer changes the code and breaks something, I can tell straight away and slap them with a wet bus ticket and an invoice.

[SBarnes]

Hi Ryan,

Whilst I agree with you that an embedded reference and just the plugin as shell would cover this, I know it's something Jiwa are not a fan of as it could create an issue that one of their customers could end up with the situation of the developer and the source code disappearing into the sunset where as if there was a way to encrypt the plugin and Jiwa had issued the keys then at least they would have the ability to decrypt the code if necessary.

I also agree with you that it would stop tampering with source code and the possibility of side effect where changes in one plugin can cause trouble with other plugins, by the plugin being able to be "locked" at least you would be guaranteed the code hadn't changed within a specific plugin. We've had the situation where a little bit of knowledge is dangerous and an outsider not familiar with the code has made changes that cause a problem.

[Mike.Sheen]

my question was about something way more trivial (which Mike has answered more-or-less as I expected).

On that... I have recently done a plugin which adds a WPF control to one of our Windows Forms - so we could grab the latest Actipro Syntax Editor for WPF and host that in our plugin maintenance form as a replacement for the current Winforms control and then we'd have all the nice new toys they've added included C# 6.0 and string interpolation, among other other cool things. Logged as improvement DEV-7223.

If we are talking stuff in terms of plugin functionality I would prefer to see the following
1. Support for encrypting source code, where Jiwa might control the master key of each JSP as IP protection.

IP protection of plugins is something that's been coming up more and more recently. We're looking into it - Logged as improvement DEV-7224.

2. Support for Source control such as link to GitHub.

Logged as improvement DEV-7225 DEV-7226 - linked you the wrong issue - fixed now.

[Mike.Sheen]

Whilst I agree with you that an embedded reference and just the plugin as shell would cover this, I know it's something Jiwa are not a fan of as it could create an issue that one of their customers could end up with the situation of the developer and the source code disappearing into the sunset

This was one of the core directives given for the the plugin system when developing it - to not leave customers vulnerable to authors unable or unwilling to maintain customisations.

Just a few months ago, I was tasked with upgrading a version 6 customer who had encrypted stored procedures, obfuscated VB Script and other nasties which validated our philosophy on keeping customisations maintainable in version 7. It wasn't a fun ride, and in this particular case what they were attempting to protect was pretty much just inflated ongoing maintenance costs - nothing was built to be reused or remotely looked useful outside the customers specific business scenario (which had changed a lot since the customisations were implemented). We certainly don't want situations like that, and will not encourage or empower developers to do this.

But, as you suggested, a compromise where the IP is protected AND the customer is protected in some way would be ideal.

The legalities are probably going to be the biggest hurdle here. If there was a system where customisations can be published to customers and protected from piracy - yet we (Jiwa) have the ability to maintain the customisation if need be - what would constitute the legal right for us (Jiwa) to step in and do so? Would the original author making demands of unreasonable compensation be considered grounds for us to step in and take over their IP? If it was deemed "abandoned" - then what is the measure of "abandoned"? - if they died does their next of kin inherit the rights to that IP and can we legally also take on the maintenance of that IP?

[SBarnes]

Having been and still being involved with upgrading a Jiwa system that is 15 years old and the previous development company was long gone where the only saving grace in this case was the customer had a DVD with the source code on it to be able to interpret what the thing actually did even though none of the original source code could be reused but no one had a full picture of what it did and at the end of the day the old code was the the only total source of truth.

I agree protection for both sides is warranted but perhaps the easiest way to protect the rights of all would be that if a protection system was put in place then developers would be acknowledging that the developer of the protection system namely Jiwa could make that decision at their discretion. I would definitely trust that.

I agree with Ryan's original comment where "bespoke work" is concerned in that if someone commissions a piece of work then they should have right to continue to use it and shouldn't be held to ransom.

I do however think that where something generic is developed by a developer that they have undertaken to develop to on sell needs to be protected also and unfortunately something just done as a plugin doesn't currently get that protection.

By the way I like DEV-7225 and DEV-7226

[SBarnes]

Will the standard Jiwa plugins such as web api use any of the compile switches and can you provide an example of how to use the new feature?

[Mike.Sheen]

Will the standard Jiwa plugins such as web api use any of the compile switches and can you provide an example of how to use the new feature?

No, the web api will not use this - not in SR2 anyway as that issue, as it turns out, could not be addressed in a service release - it's been dropped from SR2 and we now just have the issue targeting 07.02.01 - DEV-6994 .

What are you having trouble with in the web api that you think compiler optimisations will help with?