Plugin/Lib Structure

[Dar Scott]

On Aug 28, 2006, at 1:56 PM, Scott Rossi wrote:

> I have several library stacks that I would like to store as  
> substacks in a
> single master library stack for ease of management/updating.  Some  
> of the
> substacks must be loaded as frontscripts, the rest are to be loaded as
> backscripts.  Am I facing any issues with this orientation?

That depends on whether you or others using the master library stack  
would, at times, want to include that as a substack of another stack,  
say when building a standalone.  I have assumed that that is the case  
in some of my library stacks and thus avoid having substacks of the  
library stack.  I don't really know how others use library stacks.

I have stored compressed library stacks in properties.  With some  
tweaking it is possible to use those without saving to disk.  This is  
especially useful for libraries needed rarely, libraries variations  
that are selected based on the environment, or libraries that must be  
loaded after an external is installed or put into a temporary location.

If a library is used only as a front script or back script, you might  
consider putting each into a button or other control on a card in  
your master stack.  This might be simpler.  (I have a vague  
impression that stacks as front scripts are slower than buttons as  
front scripts, but I have not measured that and have no idea why that  
would be so.)

The current darzTimer plugin has versions of the 'darzTimer Helper  
Library' stacks in properties.  Some versions need an external and  
that external exists where temporary files go momentarily as the  
library is set up.  Right now the darzTimer plugin is much like your  
master library stack and the helper much like your other library  
stacks.  In the future, after I get some more feedback on how  
darzTimer is working out for folks, I'll augment it so users can  
install a 'darzTimer Library' where they want and use that in  
projects.  It would be like your master library and would use the  
appropriate version of 'darzTimer Helper Library'.  In that version,  
the darzTimer plugin would be simply a client of the 'darzTimer  
Library'.  That library would have no substacks, which--depending on  
folks' build habits--might be handy.  For example, I could make--in  
that future version--the 'darzTimer Library' a substack of the plugin.

If the substacks are very large, then load time might be a factor.

However, I don't know of anything inherently wrong with library  
substacks.

Dar Scott