On 30 May 2012 18:36, Igor Stasenko <[email protected]> wrote:
> On 30 May 2012 16:04, Ben Coman <[email protected]> wrote:
>>
>> What ideas are floating around about mixing open source and closed source
>> using Pharo?  I am implementing an IEC Standard object model for electrical
>> power systems to provide a platform for developing electrical applications.
>>  I am considering the case where a company may maintain the model of their
>> electrical power distribution network in the open source platform, but then
>> buy various commercial plug-ins perform different calculations upon the
>> shared model.  Here are the options I can imagine...
>>
>> 1. Using fuel to load binary packages within the one image without the
>> source.  Currently available technology but viewing and decompiling bytecode
>> is still possible - but to what degree this enables reverse engineering I am
>> not sure.
>
> Decompiler is able to fully reproduce the source code of method.
> only variable names is lost, but you can see everything else quite clear.

I don't know the conditions, but Decompiler can certainly keep
variable names _sometimes_. Maybe Pharo's and Squeak's Decompiler have
diverged? Or maybe it's because the .changes file is available or
something?

frank

>> 2. Having VM support for restricting displaying/decompiling bytecode.  To
>> avoid the ease of switching to another VM without this restriction, the fuel
>> package could be encrypted with a key match one compiled inside the required
>> VM.
>
> this is not an option.
> A current Debugger implementation implies that you have access to CM 
> bytecodes.
>
>>
>> 3. Running multiple images on a single VM such that the VM passing message
>> calls efficiently between the two images like an "enterprise bus*" - one
>> open source and one closed source.  Any common base objects between the
>> images might be shared on a copy-on-write basis.
>>
>>
>> What are your thoughts?
>>
>
> I think option 3 is most vital:
> you can communicate between two images like between two parties who
> don't trust each other (so images should handshake, use encryption
> key(s), and try to log-in one to other), then if succeed, one can be
> able to see source code  use  remote debugger etc
> Nothing new under the sun...
>
>> cheers -ben
>>
>
>
>
> --
> Best regards,
> Igor Stasenko.
>

Reply via email to