[V4RB] Macho VComponents folder is 22mb???

[Shaun Wexler]

On Aug 25, 2006, at 3:20 AM, Dave Addey wrote:

> Hi Shaun,
>
> Thank you for all of the explanations!  It all makes a lot of sense,  
> and
> does sound very elegant.  It leaves me with one question, and an  
> emerging
> opinion of the route I personally would take.  The question first:
>
> What is VX?  Maybe I just haven't been following the mailing list :-)

VX is the Valentina "X" project, only for Mac OS X.  Experimental high- 
performance database system developed for MacFOH.  It has so far given  
us the possibility of an all-in-one Valentina.framework such as I've  
described, as well as the elimination of embedded ICU libraries, and  
many other upcoming features.  It is currently private, only used by  
MacFOH (and possibly a few others, I'm not sure about).  In the  
future, this and the other things I've been describing will be part of  
"VX", and may be offered by Paradigma as the next-generation Valentina  
implementation.  We will be working on turbo-charging the kernel,  
leveraging multiple CPU cores, AltiVec/SSE, etc.  ;)

> And my opinion: Although the approach you describe sounds very  
> elegant, I
> don't like the fact that it requires something to be installed in
> /Library/Frameworks.  This means that if someone uninstalls my app,  
> they
> would have to know to uninstall Valentina.framework from /Library/ 
> Frameworks
> as well.  Okay, they could just leave it there, but that's not very  
> good
> practice!  It's entirely possible that they won't ever use another  
> Valentina
> application again, and they may have a large amount of disk space  
> taken up
> by the framework.
>
> The big advantage of having the framework *just* inside my app is  
> that it's
> all in one place, and they can simply delete the application bundle  
> and it's
> gone.

I consider this a non-issue.  In your software manual, you can  
describe the de-install procedure and recommend that they delete the  
shared framework if no other Valentina-enabled apps depend on it...  
but with the self-repair ability of the plug-in API, even if they  
delete the framework, another app can simply unarchive and re-install  
it.

If you download and run a "lite" app, say App2 is a 1 MB download, and  
it find an existing compatible framework, it could self-copy it into  
its own bundle (albeit not compressed or signed) and then App2 would  
become (say) 23 MB total on-disk with the installer pkg embedded, and  
whenever necessary it could re-install the 22 MB Valentina.framework  
itself by simple copy, or it could download a 9 MB compressed/signed/ 
encrypted version for updates, etc.  The reason it couldn't re- 
compress an already-expanded framework is due to the public key  
cryptography required for its code-signing.

> This is not to detract from your idea - it still sounds good - but I'd
> really like to just be able to put the framework (or Vcomponents) in  
> my app
> bundle and not touch /Library/Frameworks.  In fact, wouldn't doing so
> require the user to have Administrator access?

Yes.  To install the framework into /Library/Frameworks would require  
an admin password authentication dialog.  However the framework would  
work equally well in ~/Library/Frameworks and could be installed  
without a password.  I believe the user domain is consulted first,  
then local, system, and finally network (or was that eliminated for  
security?)...

-- 
Shaun Wexler
MacFOH
http://www.macfoh.com

"I refuse to answer that question on the grounds that I don't know the  
answer." -- Douglas Adams