I like the summary of use cases. 

Of the three (immutable;extensible;user-specific) I think the most
important two are user-specific & immutable (in that order).  

If a user has a locked down computer with no admin rights, they can
install J using the user-specific method. If the user has admin rights
to the computer they can choose to install using the immutable method
(which would also involve installing the user folder to "C:\Documents
and Settings\user\My Documents";"/Users/user/Documents";"/home/user/" ).

Eric suggested that install to _Program Files_ under Vista is a
"nightmare". I have had very little experience with Vista, so the
following is potentially off base but...
Eric your description of the Vista problems implies that they are caused
"if a non admin program writes a file to program files...".  
Are the problems resolved if the user installs with J with Admin rights
if they choose to do an immutable method install?

I agree with Eric that addons should be part of the system rather than
the user and that the requirement of Admin rights to run JAL in the case
of an immutable method install is fine.

The "ability to recognize different non-adjacent locations for system,
addons, user" is pretty desirable. But isn't this already "solved"? The
location of system is given by INSTALLFOLDER_j_, and the ~user location
can be defined in Profile.ijs (which can be somewhere other than the
INSTALLFOLDER if specified in the shortcut that starts J).  

For this reason I don't understand the restriction of the new
Application Distribution - Installer (great addition by the way) that
the ~user folder must be installed under the INSTALLFOLDER. What am I
missing?

Coping with the different use cases and OSs with an installer will
probably significantly increase the complexity of the installer. For now
I'd be happy if only the simplest & most accessible method
(user-specific) was handled by the installer, but there were documented
methods of how to manually achieve one or both of the immutable &
extensible options.


> -----Original Message-----
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Oleg Kobchenko
> Sent: Friday, 5 October 2007 09:32
> To: Beta forum
> Subject: Re: [Jbeta] J install folders and JAL
> 
> It might be good to talk about use cases (what different
> locations) and features (ability to support different 
> locations for different things: system, addons, user).
> 
> It seems the use cases can be fit into cross-platform
> equivalencies:
> 
>  - immutable, admin-level locations:
>    Program Files; Applications and .app; /usr/lib
> 
>  - extensible:
>    C:\Documents and Settings\All Users\Application Data;
>    /Library/...
>    /etc/...
> 
>  - user-specific in home (inside or outside of Documents):
>    C:\Documents and Settings\user\My Documents
>    /Users/user/Documents
>    /home/user/...
> 
> One question is whether addons are separate or part of system 
> or user space.
> 
> Feature-wise,
>  - ability to recognize different non-adjacent
>    locations for system, addons, user;
>  - how are these locations are configured
>    (manually, in configuration dialog) and
>    where this configuration is stored (profile.ijs, etc.)
>  - should installer offer different locations
>  - possibility of more than one J installation
>    (even of the same version)
>  - when more than one end-user app is install,
>    could they share same instance of J installation
> 
> 
> --- Eric Iverson <[EMAIL PROTECTED]> wrote:
> 
> > You raise a point I have been thinking about and your 
> comment about 3 parts:
> >  immutable system, extensions, user
> > makes some sense.
> > 
> > This suggests a minor tweak to our current layout which is 
> to add addons to 
> > the user folder. This would remove the admin requirement 
> for using JAL for 
> > addons. But addons would then be duplicated and user 
> specific in a multiuser 
> > system. How much such we cater to multi-user systems where 
> different users 
> > have different addons?
> > 
> > So I come back to thinking that addons (at least for now) should be 
> > considered as part of system and not part of user.
> > 
> > I also think that JAL will be used for updates to system 
> and won't be 
> > restricted to addons. There is no reason it can't be used 
> to update the 
> > standard library and even binaries and tools.
> > 
> > If system is in a secure folder and addons is in system, 
> you will have to be 
> > admin in order to use JAL.
> > 
> > I don't mind this as long  as the user was encouraged to 
> use a non-secure 
> > folder and explicitly chose to make system secure.
> > 
> > The use of "program files..." in vista is a nightmare 
> because of the virtual 
> > backing store rules. In vista if a non admin program writes 
> a file to 
> > "program files..." it gets written to a virtual backing 
> store in home. Tthis 
> > same user runnning as admin sees the primary files and not 
> the backing 
> > store. And another user sees only the primrary files. This 
> mess is not easy 
> > to protect against and my only thought is to recommend as 
> strongly as 
> > possible against "program files..." in vista. And if it 
> isn't a good idea in 
> > vista (where most xp users will eventually be forced), why 
> induldge in it 
> > now in XP?
> > 
> > ----- Original Message ----- 
> > From: "Oleg Kobchenko" <[EMAIL PROTECTED]>
> > To: "Beta forum" <[email protected]>
> > Sent: Thursday, October 04, 2007 2:11 AM
> > Subject: Re: [Jbeta] Mac 602 beta update
> > 
> > 
> > > This works as expected, however it is a good example of
> > > installation for a J-written end-user product rather than
> > > J as development environment.
> > >
> > > The previous layout was better, when all the files and folders
> > > are observable and explore-able rather than hidden.
> > > Some things may not even work, like Find in Files, open
> > > system scripts with open dialog, etc. Writing addons into
> > > the space of conceptually immutable app doesn't feel right either.
> > >
> > > However, the dmg package is better than tgz.
> > >
> > > A closest system to compare is Eclipse: it has three parts:
> > > immutable Java runtime, extensible IDE and user workspace.
> > >
> > >
> > > --- Eric Iverson <[EMAIL PROTECTED]> wrote:
> > >
> > >> Following the many suggestions I have repackaged J602 
> for Mac. There are
> > >> still serious rough edges but it feels like progress. I 
> have not updated 
> > >> the
> > >> web site beta download page as I'd like to get some 
> feedback first.
> > >>
> > >> Mac 602 beta users:
> > >> http://www.jsoftware.com/download/j602abeta_intel.dmg
> > >> http://www.jsoftware.com/download/j602abeta_powerpc.dmg
> > >
> > >
> > >
> > >
> > >
> > > 
> ______________________________________________________________
> ______________________
> > > Boardwalk for $500? In 2007? Ha! Play Monopoly Here and 
> Now (it's updated 
> > > for today's economy) at Yahoo! Games.
> > > http://get.games.yahoo.com/proddesc?gamekey=monopolyherenow
> > > 
> ----------------------------------------------------------------------
> > > For information about J forums see 
> http://www.jsoftware.com/forums.htm 
> > 
> > 
> ----------------------------------------------------------------------
> > For information about J forums see 
> http://www.jsoftware.com/forums.htm
> > 
> 
> 
> 
>        
> ______________________________________________________________
> ______________________
> Take the Internet to Go: Yahoo!Go puts the Internet in your 
> pocket: mail, news, photos & more. 
> http://mobile.yahoo.com/go?refer=1GNXIC
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
> 
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm

Reply via email to