[V4RB] Valentina 2.0 installation

[Frank Schima]

Hi Ruslan,


On May 11, 2004, at 1:27 PM, Ruslan Zasukhin wrote:

> On 5/11/04 6:05 PM, "Brendan Murphy" <bmurf at comcast.net> wrote:
>
>
> ATTENTION:
>
>     Please go to Valentina-beta list for 2.0 discussion
>
>     http://lists.macserve.net/mailman/listinfo/valentina-beta
>
>
> ------------------------
>>> Valentina 2.0 is much more complex by structure,
>>> So it is many advantages to keep components separately.
>>> Valentina 2.0 have own plugin system.
>>
>> Please explain in more detail, what are these advantages? I want
>> to use 2.0 as I use 1.10 today as a totally embedded system within
>> my application. Having a separate folder next to my application is
>> just another support hassle I would rather avoid.
>
> I believe that we get problems similar to DLL hell,
> Only if installation of Vcomponents folder is made into some
>             __central__ place on computer.
>
> But IF Valentina developer will put Vcomponents folder into app folder,
> Then no problems. On the same computer can live SEVERAL Valentina-made
> applications and they will not conflict in any case, even if they will 
> use
> different versions of Valentina.

The problem is that now we cannot make a Valentina app that is a 
standalone file. Now we have to create a folder for our Valentina app 
and place this VComponents folder inside it. Now users will wonder what 
that is.

I think we need to be able to optionally hide this folder from the user 
in some way. Maybe allow it to be in the "Application Support" folder 
(either from /Library or ~/Library) for the application?

Also, I would rather be able to just add the VComponents inside my 
Realbasic app so it is not visible at all! Is this possible, at least 
as an option? As you know, a Mac OS X application is simply a folder. I 
know it will make the RB (or whatever) app much bigger, but I'm not too 
worried about that sometimes.

So can we somehow have these 4 options (1. Your original method - in 
/Library/CFMSupport/), 2. Your proposal - Inside the same folder as the 
application, 3. Inside the "Application Support" folder, 4. Inside the 
app itself)?

> IF you SELF will not distribute separate .dlls from Vcomponents  
> folder to
> your users then also no problems.
> If you decide to provide your users with some updates then this is up 
> to
> you. You can make installer to do that.

I agree with the philosophy, although it is generally not "Mac-like". I 
think with the alternatives I propose it might make everyone happy?

>> Without further explanation of the benefits for you, my first
>> inclination is to say thumbs down on a separate components folder.
>> Adding complexity for my end users is not a feature in my eyes.
>
> Where you see complexity?
> Explain me please.

Most users expect a single clickable app. But honestly, many important 
Mac applications are complex like this: Bias Peak, Adobe Photoshop, 
Illustrator, InDesign, ok... every Adobe app :^).

> And I can say we have no other way. Because Valentina 2.0 is SEVERAL 
> times
> more complex projects of Valentina 1.x. Valentina 2.0 depend on 
> several BIG
> third party libraries.
>
> The main problem that NOT all libraries allow link them, they are 
> build only
> in the form of DLLs. For example IBM ICU library or ImageMagic.
>
> Even if assume we can link all in one, then we will get V4RB plugin for
> single platform about 12-15MB of size. As you know REALbasic require 
> that
> all 3 or even 4 plugins for each platform was inside of single plugin 
> file.
> Image the size of this V4RB plugin! Close to 50MB. Yes this will 
> affect only
> you Brendan, but not your users.
>
> Although your users also will get always YOUR APP with size
>     your size + 15MB of Valentina size.
>
> Although Valentina 2.0 itself is only 3.5MB.
>
> -----------
> We believe that it is much better to have component based system.
> At last of end look around. Where you have see complex systems ALL IN 
> ONE?
> Why all big systems use CORBA, COM, .NET ?
> Just because when system grow to some level it is not possible and not
> effective keep all in one.
>
> Component system in ideal must allow YOU to skip some parts of system 
> which
> you do not use. For example, if you not use Pictures, then simply 
> remove
> from YOUR Vcomponents folder the image library. If you want VERY VERY 
> small
> and simple database without SQL then remove HUGE SQL parser and 
> executor
> overhead, remove ANTLR.dll and make Valentina engine 2 times smaller 
> for
> your users.
>
> Can you do such tricks if all in one ?
>
>
> ------------
> And we believe (hope) that if Valentina will have own plugin system,
> Then third party talented C++ developers will be able develop own 
> versions
> of fields, functions, indexes, importers, compressors ...
>
> How many people dream about DBF import/export.
> But we want not able yet implement it. No time.
> With plugin system this can do somebody else.
>
> We believe that OPEN SYSTEM grow faster of closed private one.
> And so on and so on.
>
>
> -------------
> I was sure that everybody on this list have told:
>     we want better SQL parser
>     we want better SQL commands
>     more features