Discover MakerZone

MATLAB and Simulink resources for Arduino, LEGO, and Raspberry Pi

Learn more

Discover what MATLAB® can do for your career.

Opportunities for recent engineering grads.

Apply Today

Thread Subject:
Code distribution with privacy

Subject: Code distribution with privacy

From: Daniel Dolan

Date: 29 Aug, 2012 20:08:08

Message: 1 of 4

I have a large program that I distribute to wide range of MATLAB users. To keep things clean for the end user, I distribute the program with a main function and a private subdirectory. Suppose that these items are stored in directory called 'program':
   /program
      main.m
      /private
that the user can add to their path. The 'private' directory contains many functions and data files, but this is transparent to the user.

As the program grows in scope and capability, the 'private' directory is becoming difficult to manage. I'd like to break the files up into meaningful subdirectories, but MATLAB doesn't seem to like this. Class files can't go in a private directory, and package files seemed to be ignored if they're inside one. I could move the packages outside the private directory:
   /program
      main.m
      +local/
      /private
but because 'program' is on the path, users would have access to the local package, which I'm trying to prevent. Partly, this is for security, but I'm also trying to avoid potential name conflicts.

Does anyone know how to create a structured private directory? I know it's possible to layer private directories inside one another, but that's not quite the same thing.

Subject: Code distribution with privacy

From: Steven_Lord

Date: 30 Aug, 2012 14:19:20

Message: 2 of 4



"Daniel Dolan" <dhdolan.spamkilla@sandia.gov> wrote in message
news:k1lsr8$qtj$1@newscl01ah.mathworks.com...
> I have a large program that I distribute to wide range of MATLAB users.
> To keep things clean for the end user, I distribute the program with a
> main function and a private subdirectory. Suppose that these items are
> stored in directory called 'program':
> /program
> main.m
> /private
> that the user can add to their path. The 'private' directory contains
> many functions and data files, but this is transparent to the user.
>
> As the program grows in scope and capability, the 'private' directory is
> becoming difficult to manage. I'd like to break the files up into
> meaningful subdirectories, but MATLAB doesn't seem to like this.
>
> Class files can't go in a private directory, and package files seemed to
> be ignored if they're inside one. I could move the packages outside the
> private directory:
> /program
> main.m
> +local/
> /private
> but because 'program' is on the path, users would have access to the local
> package, which I'm trying to prevent. Partly, this is for security, but
> I'm also trying to avoid potential name conflicts.

Packages let you namespace; in this example, if you had foo.m inside
/program/+local and foo.m inside /program, the former is called by
local.foo() and the latter by foo().

http://www.mathworks.com/help/techdoc/matlab_oop/brfynt_-1.html

One convention I'm aware of that's used by some C++ projects (including the
Boost library) is to put "implementation detail" code into a namespace named
"detail"; you could do something similar in your MATLAB code with a detail
package (and subpackages if necessary.)

/program/main.m
/program/+detail/foo.m
/program/+detail/+fileio/handleMyFileType.m
/program/+detail/+securityRoutine/encrypt.m % or encrypt.p

Users would still have access to the files inside the detail namespace, but
if you use a sufficiently scary namespace name
(+internalImplementationDetails or +doNotUseOutsideProgramDirectory for
instance) then you can make it clear that they're not for general
consumption.

If that doesn't clear up any concerns you have about users having access to
the +detail/+internalImplementationDetails/etc. package, keep in mind that
even when your files were in the private directory they were still
accessible to your users directly as long as they were willing to CD into
the private directory itself.

http://www.mathworks.com/help/techdoc/matlab_prog/f7-58170.html#bresuvu-3

In that case, step 4 in the precedence order wouldn't apply, but step 7
would make them accessible. If you REALLY don't want your users to see the
code, PCODE it. If you don't want them to be able to execute it except in
circumstances you control, that can be difficult or impossible depending on
the specific circumstances.

--
Steve Lord
slord@mathworks.com
To contact Technical Support use the Contact Us link on
http://www.mathworks.com

Subject: Code distribution with privacy

From: Daniel Dolan

Date: 31 Aug, 2012 12:06:06

Message: 3 of 4

"Steven_Lord" <slord@mathworks.com> wrote in message <k1nspa$1h4$1@newscl01ah.mathworks.com>...
>
>
> "Daniel Dolan" <dhdolan.spamkilla@sandia.gov> wrote in message
> news:k1lsr8$qtj$1@newscl01ah.mathworks.com...
> > I have a large program that I distribute to wide range of MATLAB users.
> > To keep things clean for the end user, I distribute the program with a
> > main function and a private subdirectory. Suppose that these items are
> > stored in directory called 'program':
> > /program
> > main.m
> > /private
> > that the user can add to their path. The 'private' directory contains
> > many functions and data files, but this is transparent to the user.
> >
> > As the program grows in scope and capability, the 'private' directory is
> > becoming difficult to manage. I'd like to break the files up into
> > meaningful subdirectories, but MATLAB doesn't seem to like this.
> >
> > Class files can't go in a private directory, and package files seemed to
> > be ignored if they're inside one. I could move the packages outside the
> > private directory:
> > /program
> > main.m
> > +local/
> > /private
> > but because 'program' is on the path, users would have access to the local
> > package, which I'm trying to prevent. Partly, this is for security, but
> > I'm also trying to avoid potential name conflicts.
>
> Packages let you namespace; in this example, if you had foo.m inside
> /program/+local and foo.m inside /program, the former is called by
> local.foo() and the latter by foo().
>
> http://www.mathworks.com/help/techdoc/matlab_oop/brfynt_-1.html
>
> One convention I'm aware of that's used by some C++ projects (including the
> Boost library) is to put "implementation detail" code into a namespace named
> "detail"; you could do something similar in your MATLAB code with a detail
> package (and subpackages if necessary.)
>
> /program/main.m
> /program/+detail/foo.m
> /program/+detail/+fileio/handleMyFileType.m
> /program/+detail/+securityRoutine/encrypt.m % or encrypt.p
>
> Users would still have access to the files inside the detail namespace, but
> if you use a sufficiently scary namespace name
> (+internalImplementationDetails or +doNotUseOutsideProgramDirectory for
> instance) then you can make it clear that they're not for general
> consumption.
>
> If that doesn't clear up any concerns you have about users having access to
> the +detail/+internalImplementationDetails/etc. package, keep in mind that
> even when your files were in the private directory they were still
> accessible to your users directly as long as they were willing to CD into
> the private directory itself.
>
> http://www.mathworks.com/help/techdoc/matlab_prog/f7-58170.html#bresuvu-3
>
> In that case, step 4 in the precedence order wouldn't apply, but step 7
> would make them accessible. If you REALLY don't want your users to see the
> code, PCODE it. If you don't want them to be able to execute it except in
> circumstances you control, that can be difficult or impossible depending on
> the specific circumstances.
>
> --
> Steve Lord
> slord@mathworks.com
> To contact Technical Support use the Contact Us link on
> http://www.mathworks.com

Steve,

Thanks for your response. I started looking into packages after my post, and they achieve part of what I'm looking for. I am confused about managing communication between function in a package without referencing the top package level. For instance, I created the following file structure.
   program.m % this trumps the +package for tab completion
   +program/
   +/program/+graphics
   +/program/GUI.m
   +/program/+graphics/functionA.m
   +/program/+graphics/functionB.m
Suppose the graphics package is created independently from the program package and functions "A" and "B" reference each other. This means there are "graphics.functionA" calls in function B and "graphics.functionB" calls in function A. When I place the graphics package into the program package, don't I have to add a ".program" to each call? It would be tedious to modify lower level package functions to include the complete package tree. Also, it seems that higher level packages must use the entire package tree rather than just the subtree, e.g. GUI.m must call program.graphics.functionA instead of graphics.functionA.

I'm not terribly concerned about users reading the code, and in some cases will pcode or compile the program for distribution. My chief concern was protecting the users workspace. Sometimes my program will have a generic file name ("readfile.m") that might trump something on the end user's workspace. For a time, I had my programs alter the MATLAB path during execution and restore the previous settings on completion, but that's not always safe.

Dan

Subject: Code distribution with privacy

From: Daniel Dolan

Date: 3 Sep, 2012 21:54:07

Message: 4 of 4


OK, I think I've found a suitable workaround. I think some tweaks to the "import" function are sorely needed. I'll submit a feature request and may post my crude solution to the File Exchange.

Dan

Tags for this Thread

What are tags?

A tag is like a keyword or category label associated with each thread. Tags make it easier for you to find threads of interest.

Anyone can tag a thread. Tags are public and visible to everyone.

Contact us