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

[Dave Addey]

Hi Sean,

This may be the preferred Apple way of doing things, but I would still much
rather offer a complete download, with the Vcomponents inside my
application's bundle, even if this means the download is bigger.  Many
applications do this for private code (and frameworks) they use - just look
inside Photoshop CS2's bundle, there are 24 private frameworks in there in
the bundle's Contents/Frameworks/ folder.

I would be quite happy if V4RB was *packaged* as a framework, but only if I
could choose to place this framework inside my application bundle, rather
than having to place it at /Library/Frameworks/.  I don't release new
versions of my software that often - certainly no more often than new minor
releases (2.x) of Valentina are released - so I would be unlikely to benefit
from the download speed benefits of a framework installer.  And I really
don't want to have to ship an installer of any kind with my application,
even one embedded in the application bundle.  I use the "copy this folder to
your Applications folder" approach, and it makes support issues non-existent
for application install.

Just my 2 pence - I'm sure other people will think differently!

Dave.

> From: Shaun Wexler <dev at macfoh.com>
> Reply-To: Valentina Developers <valentina at lists.macserve.net>
> Date: Thu, 24 Aug 2006 16:13:22 -0700
> To: Valentina Developers <valentina at lists.macserve.net>
> Subject: Re: [V4RB] Macho VComponents folder is 22mb???
> 
> On Aug 24, 2006, at 3:57 PM, Ruslan Zasukhin wrote:
> 
>> On 8/25/06 1:33 AM, "Shaun Wexler" <dev at macfoh.com> wrote:
>> 
>>> The logical step is to have one universal "Valentina.framework"
>>> stored
>>> in /Library/Frameworks, to which all app's can link.
>> 
>> How this differ from /usr/local/VComponents ?
> 
> /Library/Frameworks is the proper location, as defined by Apple.  The
> VX project bulids the all-in-one Valentina.framework to be much
> smaller than the combined dylibs of VComponents, and it is faster and
> more efficient in operation, due to the lack of dyld stubs and
> associated overhead, not to mention C++ code duplication, etc.  The
> total framework which encompases VShared+VKernel+ICU is only 21 MB as
> a Universal binary for Tiger.
> 
>>> I can write some code for applications to download/embed/install
>>> their
>>> minimum version of Valentina.framework, and install a newer version
>>> into the system if necessary.
>> 
>> Sounds interesting. But not all developers/apps can rely on online
>> connection.
> 
> Exactly, which this fulfills by allowing the installer for Valentina
> to be embedded within the app.  The developer can choose to offer a
> downloadable app version which contains a "lite" plugin that will use
> the existing Valentina installation in /Library/Frameworks, and/or can
> download a newer version from the internet (if no embedded copy is
> included in its plug-in package).  Simple; some of my other apps use
> the same technique.
> 
>> What scary me in this design: is versions of frameworks or dlls.
>> 
>> Yes I know that frameworks can contain few versions.
>> But then we again go in trap of big size?
> 
> NO!  Smaller, because lack of individual dylibs and stubs, etc, and it
> places all resources in a well-known location and they are loadable
> using standard bundle API's.
> 
>> Valentina is in active development, we produce versions not so often
>> like
>> this was in 1.x but still quite often.
>> 
>> * For example, how you image shipping of 2.4.1 and 2.4.2 in such
>> design?
>> 
>> * How will co-exist on the same computer 2 apps:
>>     one made with V4RB 2.4
>>     another with V4REV 2.4.2   ?
> 
> When you reach a point of version incompatibility, then the framework
> version in bumped from "A" to "B", etc, and a framework can itself
> contain multiple versions within the same bundle if necessary.  This
> allows backwards compatibility for older app's, because they are built
> against a certain framework version, even though the framework path
> points to the bundle wrapper directory... that's why frameworks exist,
> for this reason.
> 
>> Apple's OS X 10.4 was about 10Gb on HDD if I not mistake.
> 
> Panther is 1.5 GB - 2.3 GB.
> Tiger is only 2 GB, up to 6 GB with developer tools and no extra
> printer drivers or localizations.
> Leopard is proportionately larger, but NDA precludes... although I can
> say yes, libraries, frameworks and app's are built fat with 4 arch's
> each.
> 
>> 10.5 as we see, is going to be 4 times bigger? Because each dll and
>> each
>> framework should go in ppc32, ppc64, x8632, x8664 ?
> 
> To compare, on Leopard, Calculator.app is 1,138,370 bytes on disk.
> 
>> I wonder if 10.4 is shipped already on few DVDs? :-)
>> 
>> All this sizes somehow sounds shocking ...
> 
> Yes.  Don't ask me about how Leopard performs [currently] either; you
> might not like the answer...  ;)
> 
> -- 
> Shaun Wexler
> MacFOH
> http://www.macfoh.com
> 
> 
> _______________________________________________
> Valentina mailing list
> Valentina at lists.macserve.net
> http://lists.macserve.net/mailman/listinfo/valentina