8 replies to this topic

[andykay]

Native export allows you to export & import RUN TIME only versions of functionality that prohibits viewing function code...This has always worked as it should from v1.0.

Glovia, uses SL, which does not allow you to have a RT Only version of functionality where the code is not visible.

My company is going to be GIVING Glovia code that I developed both at this job, but also code that I brought with me to my current job . The code that I developed after starting, I understand they can do with what they want, but how do I protect the core functionality I developed outside this job, and at the same time allow SL genning of other functions?

I've tried to Export in Native, removing the SL code, then Importing the RTO version back in Native. This only worked halfway in that functionality that has already been genned still worked. BUT, if I regen the functions in SL where we do our coding, since the Native code is now not in SL I get Gen Errors. I've tried all possible configurations of SL4U #8, but to no avail. I do not wish to gen all the functions that use my code in Native as, as poor as SL is, it's still better than Native.

Any ideas?


AK

Edited by andykay, 07 April 2009 - 03:05 AM.

[Richard Bassett]

I'm not absolutely clear what your 'problem' code is Andy, but, if you're talking about global logic and there is a requirement to regen functions referencing that global logic then the source code for the global logic has to be present - there is nothing you can do to 'fix' that, global logic is not 'independently compilable' in PROIV.

This is a longstanding problem of sorts - if global logic could be compiled independently there would probably be a bunch of add-on libraries available for PROIV from third parties because it might be commercially viable. However, as far as I know, this is not something at all likely to change.

[Chris Pepper]

AFAIK the Superlayer bootstraps are entirely separate from the ProIV bootstraps. So you have Superlayer source which generates ProIV source which generates ProIV run-time.

A Function cannot exist at the Superlayer level in a "run-time form", because this is just a repository of source code.

[Chris Mackenzie]

as poor as SL is, it's still better than Native.

Any ideas?

Ideas? No, generally, I have no idea. But, in response to your comment: No, it isn't.

SL produces inefficient, unmaintainable code. Encourages bad programming practice and was always a bad idea.

jm2c.

[Glenn Meyers]

If the client is just receiving the code, do your import/export from Native.
That will have all the functionality without giving away the source.

[DARREN]

if global logic could be compiled independently there would probably be a bunch of add-on libraries available for PROIV from third parties because it might be commercially viable. However, as far as I know, this is not something at all likely to change.

Richard,

I think that the functionality provided with server side objects in 6.2 now addresses this issue. Thus a PROIV function can reference an object which is independent of the PROIV code itself, much like an external subroutine used in the LINK command.

[Tony Waszkiewicz]

"...My company is going to be GIVING Glovia code that I developed both at this job, but also code that I brought with me to my current job . The code that I developed after starting, I understand they can do with what they want, but how do I protect the core functionality I developed outside this job..."

Andy,
Does your employer know that you are using code you "brought with you"? I doubt they would want to be reliant on a piece of code that they don't have the source and rights to.

[andykay]

I doubt they would want to be reliant on a piece of code that they don't have the source and rights to.

Tony,

You show me a ProIV programmer that says that they do not take with them the knowledge, ideas, and solutions learned from one job to another and I'll show you a wooden puppet with a VERY long nose. This is what makes one person more desireable than another when a company is considering 2 people for the same job...their knowledge base. If we/programmers did not take with us what we have learned from our previous experiences, then we'd all be newbies at the start of each job instead of someone who can hit the job running.

Technically, each site I implement the code at has the rights to the code, as the code has to be physically key stroked in at every job location I bring it to, because I don't make use prx/slx files to implement the functionality. For as I may leave empty handed when I leave one job for another...I never leave a job empty minded ...Do you?


AK

[Glenn Meyers]

The rights to ownersip of code is different in the US than in Europe.
Every state is different also.
In most states, if you do not sign a release any code you create is written by you and bleongs to you, not your employer.
This was the law in Illinios the last time I looked into it.
As it was explained to me by my lawyer, the law treats authorship as a copywrite. You develope it at your work, but unless there is a signed agreement the code goes with you to your next employer.
Youi allowing them to use the code maks it a gift, so that you cannot make them sotp using it when you leave.
Yopur bringing hte code into their environment without charge makes what your brought in a gift as well and it is possible you relinquished your right to have any say as to its disposition.
That was the law when I was running an independent company. I had to check because I was writing stuff for customers I planned to sell to others and I needed to make it clear to myself and to them who owned what.

Glenn