Re: PATCH: NSPathUtilities etc

[Sheldon Gill]

Hallo, Roland. Guten tag.

> I have read your posting with great interest, and have a little bit bad
> <snip>
> usable all the same (it is that what I understand why you are doing this). 

That is sort of why I'm doing this. Really, I'm trying to isolate the 
application level from having to discover too much about the platform 
environment on which it's running. One day, perhaps, you'll be able to drag 
your ELF executable to any OS (with ELF support) and have it just work.
Also, I want gnustep-core to behave in a way which is platform friendly. 
Forcing a file heirarchy and such things are to be avoided.

Unification at the application layer is definitely desirable although not 
always possible.
My effort is two fold, unification at the application layer AND behaviour 
modification to suit the platform. That is, to behave in a way which is 
consistent with users expectations for that platform.


Let me address you concerns en-block, rather than in response to each 
paragraph. It'll make my response much more coherent.

Firstly, GNUstep under windows current requires setting GNUSTEP_SYSTEM_ROOT as 
an environment variable. If it's not set, it defaults to the build variable 
GNUSTEP_INSTALL_PREFIX {which is usually "C:\GNUstep" from memory.}
So, if your applications are simply drag-installed they _all_ will have the 
_same_ GNUSTEP_SYSTEM_ROOT. Doesn't matter which directory you've installed 
them into.
I believe that you are confusing the SYSTEM_ROOT path with the ability to load 
Bundles from the application directory. The Bundle loading system hasn't been 
changed (and won't be). The mod only adds a missing feature which was loading 
Frameworks from any directory in the domain heirarchy. It's been marked as a 
FIXME for a while now...

Secondly, Setup is required in the Windows application distribution model. You 
can't "Add/Remove Programs" without having set things in the registry. There 
are other features which similarly pretty much mandate a setup application 
for application distribution.

Unix isn't very self-contained for applications, either. That's why NeXT 
cameup with Bundles.

Thirdly, a configuration file in "/etc" is the Unix model for system-wide 
application preferences. It can't be applied to Windows. The only reasonable 
place for such a thing under Windows would be in the \Windows (or \WinNT) 
directory. That's not recommended by Microsoft. It's alien to normal Windows 
system administration. It also very quickly runs afoul of Windows System 
Repair and other protection mechanisms.

The right way to have a "system-wide shared preference" setting under Windows 
is the registry. I'm not about to launch into yet another debate about the 
pro's and con's of the registry. It's there and we're expected to use it. 
There isn't a reasonable alternative IMHO.

Although Windows does support environment variables, they're added to help in 
porting Unix applications. There are quite a few issues in systems 
administration in that regard.

Hence the decision to put the configuration into the registry. At this stage 
it only defines the root path for the shared resources.

Which brings me to the fourth point: "shared". Read the OpenStep spec. Read 
the GFHS. It's about 'sharing' resources and being able to locate such things 
cleanly. Putting everything into the application's own directory is _not_ 
sharing. If you're not into sharing, then you can ignore SYSTEM_ROOT and 
LOCAL_ROOT and NETWORK_ROOT. Of course, you're not going to derive the 
benefits of sharing in that case.


> But what are my concerns... Well imagine you are using more than one
> <snip>

Different versions of GNUstep won't necessarily clash. The specification of 
SYSTEM_ROOT is _supposed_ to be shared. That's the point of it. You don't 
need version dependant keys for the _ROOT path specifications.
You might need version dependant keys for other things. It's not so much of a 
nightmare to do so. There is well established practice in that arena. 
Microsoft do it themselves with different versions of MS-Office.
Like most things, intelligent use will keep things in order.

> We are encapsulating GNUstep (as DLL together with its resources) in the
> <snip>

The changes won't break your applications. You can still put a DLL and the 
Resources directory into the application's folder. You won't need a setup any 
more than you do now.

Also remember, under Windows code from a DLL loaded from the application's 
directory isn't shared. So if GNUstep requires 10Mb and you're running 10 
applications that's 100Mb just for GNUstep.
For the shared case it'll be the same 10Mb regardless of the number of 
applications using the library. You're trading DLL conflict potential 
reduction for an increase in resource usage.

> And much more pain will be if you use different applications at the same
> time, settings will not be unique to each app (eg. GNUSTEP_SYSTEM_ROOT
> is different for each application). This is all really bad! And that
> is only one problem that will arise when doing this.

Having a different SYSTEM_ROOT for every application is bad. It means multiple 
unicode maps, character tables and timezone data. Imagine someone using your 
applications decides to use a different language. You're going to have to 
find _all_ the installations and update them. Otherwise some applications 
will use the language and some just won't. Very confusing for the user.

> (this is just a very first and basic idea for avoiding registry)

Having a configuration file is already implemented. Modifying things so it's 
sourced from the application's directory won't be very difficult.


Regards,
Sheldon