[openbeos] Re: glasselevator-talk@bug-br.org.br

"Mikael Jansson" <tic_khr@xxxxxxxx> wrote:
> (Moving over the thread to GE-talk now, I think it's where it 
> belongs.)

I'm not on GE-talk. Apologies for the reply here. :P
 
 ...
> On that note, should we somehow lock the 
> settings from apps by adding a BApplication
> member function to get the location of the settings 
> folder? For example, ~/config/settings/
> tic_software/ticWorkspaceGadget, 
> and then whatever settings file within that folder.

I wouldn't mind a BSettings class, or something provided by 
BApplication. I've been in favor of a BFolder previously, (leaving it 
up to the app to store one unified settings file, or splitting settings 
across multiple files),  but if ~/config/settings is indeed to be 
limited to settings only, it might be better to provide a single file 
interface. (BFile, BPositionIO, or something C-ish?)
 
 ...
> The problem is where to break up the settings/data:
> One scheme would be to place the app's skins in 
>     ~/config/data/{app},
> and the settings (i.e., what skin to use) in 
>     ~/config/settings/{app}.

I'd like that.

> Plugins (or, add-ons as we say in Beish), goes in ~/config/add-ons.
> But you knew that, right? ;) 

I'd prefer if ~/config/add-ons was for Haiku add-ons only. 
(Translators, Tracker add-ons, input_server add-ons, device drivers, 
...)

If we would want to create an uninstaller, based on, say, application 
signature, it would be easier to [offer the choice to] remove these:

wherever/ {app folder}
~/config/settings/ {app-sig}
~/config/data/ {app-sig}

Pretty straight forward. If apps [are made to] follow this standard 
there is no need for a more elaborate installer.

Knowing which app created a certain subfolder within
~/config/add-ons is definitely possible using attributes
and/or a better installer (to would keep track of stuff),
but IMO it's much simpler to rely on the app-signature.

Creating the uninstaller would be dead easy.

 ...
> we still need to deal with the icky UN*X ports 
> spreading their directories and files all over the place.

I'd prefer some kind of onioning filesystem that would let you overlay, 
for example, all Perl files, on a "standard" Unix-like filesystem 
hierarchy, being able to switch the Perl "package" on and off on the 
fly. (virtual, as opposed to links or files being copied into place on 
some existing filesystem.) Loose files should still be allowed to be 
spread across this semi-virtual filesystem (for example by some manual 
untar/configure/make activity), but, you should be able to "corrall" 
such a set of individual files spread across multiple folders into one 
package. On the fly. 
 
The back-end stored packages would be zipfiles or some other attribute-
preserving format. Preferrably one that allows for non-compressed 
archives, so we spend as little time as possible uncompressing. (or 
(re)compressing)

There's a whole lot of implementation detail missing in this vision, 
(writing to files owned by a package, if there's a good way to support 
config files, if one should allow virtual sets of files that are not 
backed by a package but by something else, (network stored settings?)), 
but that's the general idea: Packages, and the easy creation of new 
packages by corralling loose files.

Essentially a sandbox (you said it! :) except somewhat more complex 
than mere symlinks from /foo  ->  /boot/beos/foo

It would have to be implemented as a filesystem addon.

I'm sure Be would have labeled this a "3'rd party opportunity", 
(essentially something they found interesting but did not want to 
implement themselves), and I fear the Haiku heavy-weights will follow 
this tradition. :}

/Jonas Sundström.                 www.kirilla.com

Other related posts: