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

[Dave Addey]

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 :-)

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.

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?

As I said before, these are just my requirements - others may disagree!

Dave.

> From: Shaun Wexler <dev at macfoh.com>
> Reply-To: Valentina Developers <valentina at lists.macserve.net>
> Date: Fri, 25 Aug 2006 02:41:47 -0700
> To: Valentina Developers <valentina at lists.macserve.net>
> Subject: Re: [V4RB] Macho VComponents folder is 22mb???
> 
> On Aug 25, 2006, at 2:09 AM, Ruslan Zasukhin wrote:
> 
>> Right, and this is where I see this trap of size.
>>     Framework with A + B + C will have 21 * 3 = 63 MB right?
> 
> Possibly.  The goal is to maintain compatibility with existing public
> API, where future API can be added in the form of new (or newly-
> exposed) functions, but future revisions do not change the fundamental
> behavior of existing/previous API, and maintain binary compatibility.
> 
>> Can work this:
>> 
>>     App1 install VSDK.framework - vers A
>> 
>> Later on the same computer, other installer of other app2 installs
>>                  VSDK.framework - ver B
>> 
>> So can they go into the same folder and live together?
> 
> If I write a Valentina.plugin API, app's would call ValentinaPlugInInit
> () instead of ValentinaInit(), and otherwise nothing would have to
> change.  Here is a scenario:
> 
> Let App1 be a Panther/Tiger app which depends on the current 32-bit
> API in Valentina.framework/Versions/A/Valentina, and let both App2 and
> App3 be Leopard-only apps which each depend on the new 64-bit API in
> Valentina.framework/Versions/B/Valentina.
> 
> A user regularly uses App1 on his computer, and version A of the
> framework is currently installed in /Library/Frameworks/
> Valentina.framework/Versions/A/.
> 
> The user decides to try a new program, App2, and downloads it.  The
> app is downloaded "lite", meaning the Valentina.plugin embedded in the
> App2 bundle does not contain Valentina.pkg (installer package) for
> Valentina.framework/Versions/B, upon which it depends.  When App2 is
> launched, it finds /Library/Frameworks/Valentina.framework but sees
> that it does not contain the required version B, so it notifies the
> user and subsequently downloads and installs it (after authentication)
> into the existing framework bundle, so /Library/Frameworks/
> Valentina.framework contains both the A/ and B/ versions.  App1 also
> contains the compressed A/ version in its bundle, and now App2
> contains the compressed B/ version in its bundle which it requires.
> App2 can now launch quickly, as well as repair the system if the main
> framework is accidentally deleted.  Same for App1.
> 
> Next the user buys App3 from Dave Addey on CD.  The app is shipped
> fully self-contained because it includes the proper version of
> Valentina.pkg within its embedded Valentina.plugin, and will install
> it upon launch.  The user mounts the CD, performs a drag/drop into /
> Applications, and double-clicks App3 to run it.  App finds a NEWER
> version of Valentina.framework/Versions/B is already installed, so it
> links to the existing one and launches.
> 
> Any particular versioning requirements within a compatibility version
> ("A" or "B", etc) can be solved by reading the framework versions and
> using the necessary logic, but overall binary compatibility is
> inevitably maintained.  At least that's the theory...
> 
> -- 
> Shaun Wexler
> MacFOH
> http://www.macfoh.com
> 
> "Intellectuals solve problems, geniuses prevent them." - Albert Einstein
> 
> 
> _______________________________________________
> Valentina mailing list
> Valentina at lists.macserve.net
> http://lists.macserve.net/mailman/listinfo/valentina