Settings, BeOS style

Blog post by koki on Tue, 2007-05-08 18:05

In his Popular Network Preferences applications and comments blog post, GSoC student Andre Alves Garzia gives a great comparative overview of network preferences apps in OS X, Ubuntu, Windows and ZETA, as a means to look for the ideal approach for Haiku.

Andre's post actually reminded me of a few ideas that I had quite some time ago about a BeOS-like way for handling network/email/printer settings (in ZETA, back in the days when I was using it), that I think would still apply for Haiku. I don't know if they are within the scope of what Andre is doing and, not being an engineer, I don't either have a clue whether these ideas can be implemented or not. But I will present them anyway, even at the risk of exposing my sheer ignorance. :)

Those of us who have used BeOS/ZETA in the past know the goodness of how extended attributes are for certain file types. The approach of having emails messages and contact information in individual files with attributes makes your data very portable and accessible even at the file manager (Tracker) level. You can, for example, switch your email client, and still have access to all your emails and contacts, as the data remains always the same.

IM Kit screenshotIM Kit screenshotThere are some applications that take attributes a bit further in quite innovative ways. A good example that I always use is the IM Kit, which uses People files to store all IM contact info and to show online/offline status. This is a very intuitive way of presenting information related to any given contact, and it is exposed in such a way that it can be accessed at the basic file manager level as well as from applications.

By now you may be asking: what does all this have to do with Andre's post? Well, I have many times I asked myself: why not use a People file approach for settings files?

For example, let's take a network configuration: to create a network connection, you open a People-like app where you can choose the NIC, connection type (DHCP or fixed IP), and enter info like name for the connection, DNS and other various network settings. When you save the configuration, you are actually creating a network connection file (stored in a "networks" folder?) that holds all the information that you entered in attributes. This file could be accessed both directly from Tracker and/or a summary-like pref applet that would list and give access to all the existing connections in your system.

I think there would be many advantages to this approach from a user POV. First, it is more intuitive, as the network connections are exposed to the user in the form of files that can be opened and changed from Tracker. Network connections can also be easily moved from one system to the next; it would even be possible, for example, to email a network connection file to someone else for troubleshooting. Additionally, power users could use queries to poll the status of network connections, or connections associated with any given setting stored as an attribute (for example, all connections using a certain NIC). And, in the same way as IM Kit, different icons themselves could be used to show the different types of connections (ethernet or wireless) and their status (enabled or disabled), making it all even more visually intuitive.

I think this approach could be used for other settings too, like email accounts. How much easier and intuitive would it be to the user if he/she could backup and restore email accounts by just copying a few settings files and dropping them in the "email" folder!

I have no doubt that I may be missing some obvious pitfalls to this approach, and you are welcome to point them out to me. But I am sure you can still get the gist of what I am aiming at. Admittedly, maybe this is R2 stuff, but I thought I would anyway post about it, even if it's just as a way not to forget about it. :)

Comments

Re: Settings, BeOS style

I like that idea very much. It's hard to be simpler (as long as all that is live and don't need any "apply" action).

Just like you said, after any other more fancy config solution could be implemented on top if really wanted. In any case just like with the people an editor is needed even if it's just to create a new file of that type.

Monitoring from a distance the connection of a system would be lot easier (especially with that native network FS that i did read about).

The only problem is that it's not a very flexible data structure, so one really have to do some forward thinking when deciding what the attribute will be, but the choice to display such or such attribute from the tracker itself mean one could only display the useful ones even if the "struct" is far more wide.

Re: Settings, BeOS style

A file type with a set of type specific attributes usually only makes sense when there will be lots of files of the type in question, like email or people files.

Folders are nice in that they have good scalability. You can have thousands of files in a folder, but a typical BeOS/Haiku installation will have one, maybe two network interfaces.

There is no saved work in not producing graphical network preferences, as the management of the attributed connection files will be just as complex (to the system) as the network preferences. The system may still have to ask for clarification or notify the user by putting up a dialog. I don't think the attribute approach would be more user friendly or any less work to implement than the usual set of network preferences. And it wouldn't fit naturally with the other system preferences.

Attributes are usually metadata, a summary or subset of the information embedded within the file (as in email) and not usually controls (user interface) to some opaque machinery within the file. Perhaps this executable vs document (or code vs data) dichotomy isn't obvious to the majority of non-programmers. (Perhaps it's even unnatural. I suppose DNA doesn't have code/data separation.)

Attributes, as presented in Tracker (and as available for manipulation directly by applications), have very little enforced formatting. There's no way to enforce the format of e.g. an IP address and have the user not be able to enter "yankee-doodle" instead of "192.168.0.1". Instead you let the user enter whatever the attribute type (string, integer, etc) allows, then erase the input if it's bad and make the user understand what just happened. Hardly ideal.

But I think tagging the /dev/net/ interface files with read-only attributes exposing the effective settings may find some use, but not as (end-)user interface.

Re: Settings, BeOS style

Hi Jonas,

First I have to apologize: I may have given the wrong impression that I am suggesting one file per network interface, but that's not the case; it's rather one file per network profile (so to call it) what I envision. So chances are that you may have more than just one, particularly in laptops, where your net connection may vary depending on where your are. And while is this far from the quantity of emails or contacts one may have, there are still advantages.

From a purely end user POV (which this is all coming from), the code vs. data dichotomy itself is unnatural. To the non-programmer, whether it is a contact, a network profile or an email account, it is all information that he/she has to manage, and the more intuitively this information is exposed to the end-user, the more natural the whole computing experience can be.

For example, consider the scenario where a user wants to migrate his/her email. I would think that it would be more natural to ask him to go to copy the email folder and in it all the messages together with the email accounts settings that he may have. In a single step, the user is able to move his whole email environment, and it would just work. And if I am not mistaken, the attributed nature of the files would also have the positive side effect of making the location of the configuration files irrelevant, so that the migration would just work, regardless of where the files are moved to.

I did not expect this approach to reduce the complexity of the data structures that needs to be dealt with, which is probably what you are concerned about as a programmer, and rightfully so. I am coming from a purely user POV, so my concern is to make the way settings are exposed to the user more accessible in a more intuitive and portable fashion than it is today.

BTW, the issue with Tracker that you point out is well taken but easy to deal with: just make the data read-only in Tracker so that you cannot mess up the attributes. From a Tracker perspective, the value of attributes is that you can see them. There would still be a People-like app (specific to the configuration type, ie., network, email, etc.) to create/edit config files, and if the user realizes that change(s) need(s) to be made, he/she could always do the natural thing: open the configuration file by double-cliking its icon, make the changes and save. Simple, is it not? :)

Re: Settings, BeOS style

Hi Jorge,

koki wrote:

First I have to apologize: I may have given the wrong impression that I am suggesting one file per network interface, but that's not the case; it's rather one file per network profile (so to call it) what I envision. So chances are that you may have more than just one, particularly in laptops, where your net connection may vary depending on where your are. And while is this far from the quantity of emails or contacts one may have, there are still advantages.

I'm with Jonas here. I'm not sure which problem you're trying to solve. The network profiles can be stored as one single file each, so what would attributes make better? I mean, Tracker can't be used to access the network configuration and I don't think that people will want to query for a specific network profile via Tracker. Backing up the network profiles will be all the same. Simply copy the file. It's the same with the other files in the user's settings folder.

What if a user moves his preferences files to a FAT volume (any pre-formatted USB stick)? The attributes will be lost.

The email accounts example might be worth a try, but it could be dangerous because the user doesn't know that his mail folder is directly related to his accounts (he could mistakenly expose his password, delete his accounts, etc.). It's like having a "Preferences" file in the mail folder (only much more hidden).

Could you please give us a few more examples where this suggestion really shines?

Re: Settings, BeOS style

"What if a user moves his preferences files to a FAT volume (any pre-formatted USB stick)? The attributes will be lost."

Yes very good point, I can't believe that this fact has been obscured for so long, that you mustn't forget to use BFS on DVD's, CD's where you do back ups on, which is not trivial IIRC, time to get something done about it because BeOS seems easy but there are a lot of pitfalls many users are unaware of.

For the profile's to have attributes (which are updated live for status reasons) I think the only reason to have it in the Tracker with all it's attributes showed is to have the ability to click on it and activate or deactivate a profile, so indeed limited use. The only thing I can imagine is the usefulness of the 'view standard' of Tracker; it is a standard many BeOS users are used to seeing.
I imagine if the Profile is not binary that many normal users will not be very convinced of the usefulness seeing the internals of the file therefore opening a Profile should result in a pop-up of the Network Prefs showing the Profile in question.

Re: Settings, BeOS style

Hi Waldemar,

Waldemar wrote:

I'm not sure which problem you're trying to solve.

From a user POV, setting files are rather obscure. I guess what I would like to see are settings files that are easier to identify, more accesible to the user (as in, via a mouse double-click) and that make the information they contain more accessible system-wide, so that other applications can also easily use them in ways that extend functionality.

People files are a good analogy. In contrast to other operating systems where the format/structure of contact information files was mostly left to each individual application, BeOS took the approach of using People files accessible system-wide through the use of attributes. This not only allowed the use of queries in Tracker, which alone is a good thing in itself, but it also made the contact information accessible to other applications for a wide range of purposes.

The IM Kit that I mentioned in this post is a good example of how attributes can be put to work in a practical and intuitive way that is unique to Haiku. Email clients in BeOS also read email addresses from People files.

I think that, with some thought and planning, it may well be possible to make good use of attributes for certain setting files. This is where my thoughts are pointing to.

Waldemar wrote:

I don't think that people will want to query for a specific network profile via Tracker.

The visibility of the settings via Tracker is not the ultimate goal, but more of a (positive) side effect.

Waldemar wrote:

What if a user moves his preferences files to a FAT volume (any pre-formatted USB stick)? The attributes will be lost.

You raise a very valid concern, but not one that does not already exist. Any user who copies his/her People files to a FAT volume looses his/her data. This risk already exists and needs to be somehow addressed regardless (perhaps by having Tracker catch any such attempts before they happen?).

Waldemar wrote:

The email accounts example might be worth a try, but it could be dangerous because the user doesn't know that his mail folder is directly related to his accounts (he could mistakenly expose his password, delete his accounts, etc.). It's like having a "Preferences" file in the mail folder (only much more hidden).

Putting the email account files in the mail folder was just an example, perhaps not a very good one. The point that I was trying to make is that it is much easier and more intuitive for the user to relate to preference files that are visually identified as such with an appropriate icon that is stored in a logical location, and that contains the related information in a format that is more transparent to the user, and that the user can view either through double-clicking or directly in Tracker.

I doubt that accidental deletion of setting files would be a problem. BeOS/Haiku already warns users when they attempt to remove/move system files, so the same or a similar mechanism could be used (unless there any unsurmountable technical obstacles, of course).

With regards to email account password security, I am not sure what your specific concern is. If what you are concerned about is exposing passwords in Tracker, I guess this could be addressed by a "password" attribute that displays asteriscs.

Waldemar wrote:

Could you please give us a few more examples where this suggestion really shines?

The good thing about exposing settings via attributes, IMHO, is that it makes the setting values available system-wide for a variety of potential uses. I can think of apps/replicants designed to show info for all network connections (status, protocols, etc.), backup utilities used to migrate settings to a new installation, programs/utilities specific to wireless connections which could rely on a "connection type" attribute to easily pickup all wireless profiles. Even the preferences app could use the attributes to easily provide different views for the same set of information (by location, connection type, protocol, etc.). It really opens up a whole array of possibilities.

If settings files had, for example, an "install location" attribute, it would be even possible to backup and then restore the settings where they are expected to be. Or you could send a settings file with such an attribute to a friend who has the same hardware, and he/she would know where it has to saved by just looking at the "location" attribute. Even better, for the real beginner, there could be an "Install this file" Tracker add-on that would read the "install location" attribute and move the file to the proper location. Easy and simple, but powerful. These are the kind of things that I would like to see make their way into Haiku.

I am sure there are more applications that one can think of. It's a matter of being a bit creative. :)

Re: Settings, BeOS style

Hi Jorge,

Jorge wrote:

From a user POV, setting files are rather obscure. I guess what I would like to see are settings files that are easier to identify, more accesible to the user (as in, via a mouse double-click) and that make the information they contain more accessible system-wide, so that other applications can also easily use them in ways that extend functionality.

Ah, I see. First of all, there is a technical problem: Settings files often require a hierarchical structure and attributes are much too simple for storing such data. We'd have to redesign our FS to allow for hierarchical attributes.

From the user POV I agree that we need to make settings files easily identifiable and editable some way, but this doesn't have to be via attributes. A preferences editor would IMHO be much better suited for this. We also thought of making BMessage the default data format and extending it to support a textual representation similar to our driver settings. That way, you could use any text editor for manipulating settings files (esp. hidden settings which we don't want in the GUI ;). Of course, the settings files should be moved into a well-defined location (like ~/config/settings), so the user can find them, and applications need a very simple API for retrieving and storing settings (without having to care about file locations, etc.). This would solve the interoperability problem you described.

Having the possibility to graphically edit settings would be even better. I was thinking of possibly splitting the whole configuration UI into two parts: The *essential* base preferences are easily accessible through a preferences dialog. Advanced preferences can be accessed via a simple query interface (a text field available in every preferences dialog). Just enter what you want to change and a list of matching preferences will appear. This could be similar to the "about:config" page in Firefox, but more user-friendly, with GUI controls and a better matching algorithm which even compares related words (e.g., if you enter "skin" you'll also find preferences for "theme") and phonetically similar words. Well, that's the theory. I don't know if it's feasible, but it would at least help to solve the dilemma between the needs of power-users and people who want/need a very simple UI.

Re: Settings, BeOS style

Hi Waldemar,

I am not surprised that there may be technical problems in any idea coming from me. :)

Waldemar wrote:

...but this doesn't have to be via attributes.

I am not actually fixated with the use of attributes (or any other means, for that matter) to achieve any given objective. If you developers can figure out a better way to achieve the goal of making setting files more accessible and less obscure to the non-technical user, that would be good too.

Waldemar wrote:

That way, you could use any text editor for manipulating settings files...

Well, not that I cannot edit text files, but even then, this approach can be rather intimidanting for the non-technical user. And all those cryptic keywords used in the config files, they create a learning curve that you would want to avoid whenever possible. I was thinking more along the lines of a real GUI instead.

Waldemar wrote:

...esp. hidden settings which we don't want in the GUI...

What sort of settings would you not want in the GUI?

Waldemar wrote:

...with GUI controls and a better matching algorithm which even compares related words

Maybe this is an area where attributes could be used, to tag setting files and assign them keywords that identify the areas to which they are related (like the "Group" attribute in People files).

Re: Settings, BeOS style

Hi Jorge,

Jorge wrote:

I am not actually fixated with the use of attributes (or any other means, for that matter) to achieve any given objective. If you developers can figure out a better way to achieve the goal of making setting files more accessible and less obscure to the non-technical user, that would be good too.

I think the best solution is to have a fully graphical and structured way to manipulate preferences. Tracker is too simple for this. Of course, we could try to extend it such that Tracker can integrate various views on content, but that mustn't increase UI complexity.

Jorge wrote:

Well, not that I cannot edit text files, but even then, this approach can be rather intimidanting for the non-technical user. And all those cryptic keywords used in the config files, they create a learning curve that you would want to avoid whenever possible. I was thinking more along the lines of a real GUI instead.

Agreed. A GUI is preferred, of course.

Jorge wrote:
Waldemar wrote:

...esp. hidden settings which we don't want in the GUI...

What sort of settings would you not want in the GUI?

All those expert preferences which would only confuse novice users and which really aren't essential for the application or when only very few users want to change something. For example, in Tracker we removed the non-boot desktop integration option, but it should still be accessible through the settings file.

Jorge wrote:

Maybe this is an area where attributes could be used, to tag setting files and assign them keywords that identify the areas to which they are related (like the "Group" attribute in People files).

This would mean that we can incorporate preferences from everywhere into our preflets. This could be quite confusing, though. It might work for system-wide preferences.

Re: Settings, BeOS style

koki wrote:

From a user POV, setting files are rather obscure. I guess what I would like to see are settings files that are easier to identify, more accesible to the user (as in, via a mouse double-click) and that make the information they contain more accessible system-wide, so that other applications can also easily use them in ways that extend functionality.

We agree on quite a few things. :) Yes, they are often obscure. I would like for all settings to be easy to say which application they belong to, and it would be nice to be able to inspect them more easily.

Applications are able to store their settings anywhere they like, in as many files they like, in any format, using any filenames. We can only recommend good behaviour. It's hard to enforce these things without severly crippling the system as a whole.

What we can do is state our recommendations more clearly and create an API (a BSettings class available to every BApplication, maybe) that would let applications create system-standard settings with as little effort as possible and with all the nice qualities we would like: an application signature attribute that tells which app each settings file belongs to, an attribute that tells where it should live (a relative path, perhaps with find_directory() hints), a distinct settings filetype attribute, perhaps also an attribute telling the filetype of the internals, if multiple formats (flat BMessage, plain text, XML, ...) are to be allowed. This way we can have settings files open (from Tracker) in an installer/inspector that would either move the settings into place or allow

But I think the contents of a settings file is of interest almost exclusively to the application it was created for, or by. Any shared settings has to be very explicitly for that purpose, which I'm guessing /boot/*common*/config/settings are for. Otherwise, you have applications snooping on each others settings, possibly changing them if they feel confident. What if every Haiku ftp client would also list the preset connections of the other clients. Every time there's a new client created, support for the settings of this new client (its settings file format and location) would have to be added to every other already existing ftp client. Some apps would support a subset of the settings of the other apps. Some would support no other apps, and the user wouldn't know the cause or the cure of this confusion. The common-folder can perhaps provide at least a place to share settings between multiple applications, but there's a risk that this place too becomes a place for files that are closely tied to only one application. One application can propose a common standard, but that doesn't mean anyone else will follow. Haiku as a whole system has a chance to create shared application settings that are truly user-oriented *preferences* (and not merely some data presets that are tied to the internals of a certain executable) similarly to how BeOS achieved some interoperability in email and people files, but it would require some forethough, thinking about the preferences first, I think, detached from any any application, but also at the same time make the bundled Haiku applications use these shared settings. (User name, address, http proxy.. that kind of stuff.)

koki wrote:

The IM Kit that I mentioned in this post is a good example of how attributes can be put to work in a practical and intuitive way that is unique to Haiku. Email clients in BeOS also read email addresses from People files.

I hate the way the IM Kit mixes People files, which are documents to me (consisting of data, or "passive information") with application state (which contacts are online, using Tracker add-ons on the People files, even *altering* my People files. As topping on the cake, last time I tried the IM kit it started producing thousands of mostly empty people files. I pulled the plug on that one. But I've never felt comfortable with it. The idea of multiplexing the competing IM protocols is good, but the user interface isn't one that I would choose myself.

koki wrote:

The good thing about exposing settings via attributes, IMHO, is that it makes the setting values available system-wide

Application settings are available system-wide, but they're wrapped in arbitrary file formats. Only the creator/user (application) of the settings truly know what they mean. But we humans can guess. Attributes take out the fileformat parsing step, and can help a little with understanding the purpose of a setting. I don't know if querying on exposed application setting attributes is worthwhile. For what purpose? NetPositive stores its settings as attributes on a file, and in a way that makes it easier to understand and hack them, but there could hypothetically be dependecies between the attributes that we don't know about, and can not know about.

koki wrote:

If settings files had, for example, an "install location" attribute, it would be even possible to backup and then restore the settings where they are expected to be. Or you could send a settings file with such an attribute to a friend who has the same hardware, and he/she would know where it has to saved by just looking at the "location" attribute. Even better, for the real beginner, there could be an "Install this file" Tracker add-on that would read the "install location" attribute and move the file to the proper location. Easy and simple, but powerful. These are the kind of things that I would like to see make their way into Haiku.

My suggestions at the beginning of this post were in part inspired by your suggestions. In MacOS 9 and previous it is possible to double-click something that should be in the System folder and, IIRC, have the system offer to install it in the right place. Analogous to this, a special purpose application could open Settings files for inspection/editing or installation. It would be even easier than a Tracker add-on, as it would just open automatically. Tracker add-ons are for thing you need to do a lot, IMO, and not for occasional tasks.

Re: Settings, BeOS style

Hi Jonas,

Thanks for the long explanation. Let me make a few observations, as usual, from an end-user POV.

Jonas wrote:

Otherwise, you have applications snooping on each others settings, possibly changing them if they feel confident. What if every Haiku ftp client would also list the preset connections of the other clients. Every time there's a new client created, support for the settings of this new client (its settings file format and location) would have to be added to every other already existing ftp client.

Hmmm... Maybe I gave the wrong impression here. There will always be application-specific settings, and those can be handled on an application basis. But I think there is plenty of room for having standard settings that applications can share (like, email accounts, for example). These standard settings should only be changed by the Preferences app, and not the application itself. So, let's say that you have an email client, and it has an "Email accounts" menu somewhere, this would open the Email pref applet.

Jonas wrote:

One application can propose a common standard, but that doesn't mean anyone else will follow. Haiku as a whole system has a chance to create shared application settings that are truly user-oriented *preferences* (and not merely some data presets that are tied to the internals of a certain executable) similarly to how BeOS achieved some interoperability in email and people files, but it would require some forethough, thinking about the preferences first, I think, detached from any any application, but also at the same time make the bundled Haiku applications use these shared settings. (User name, address, http proxy.. that kind of stuff.)

You have summarized, in a single paragraph, what I think would be the ideal situation. Granted, this would require thought and planning, as well as compliance by the bundled applications. But I think the benefits can outweigh the effort, although I have to admit that this sounds more like a post-R1 thing.

Jonas wrote:

I hate the way the IM Kit mixes People files, which are documents to me (consisting of data, or "passive information") with application state (which contacts are online, using Tracker add-ons on the People files, even *altering* my People files.

Maybe I should have said that I liked the IM Kit concept. It may be that the implementation has not been perfected yet, but the concept is very intuitive. The notion of mixing documents with application state is probably one that only affect programmers, and does really not concern end users. For me, being able to keep all contact-related information -- and that includes IM status -- in a single place (the People file) is a real plus and very intuitive.

BTW, why does it bother you so much, when BeOS/Haiku already does this with email files? I mean, the "new/read" state of email files in BeOS/Haiku is stored as an attribute, is it no? :)

Jonas wrote:

But we humans can guess.

Does that include humans that cannot code? :P

Jonas wrote:

Attributes take out the fileformat parsing step, and can help a little with understanding the purpose of a setting. I don't know if querying on exposed application setting attributes is worthwhile. For what purpose?

Well, querying could have various applications depending on the sort of setting that you would be dealing with, and it could be even used by pref apps themselves to show different views of the relevant information (by any given attribute, for example). It's all information after all, so how you use it to your advantage depends on the information at hand and your imagination. :)

Waldemar explains that the same can be achieved by a BMessage, but then that in itself already makes it obscure to the end user. It is the nature of the attribute, which can be viewed directly from Tracker, what would make the content of the setting files easily accessible to the end user.

Jonas wrote:

My suggestions at the beginning of this post were in part inspired by your suggestions. In MacOS 9 and previous it is possible to double-click something that should be in the System folder and, IIRC, have the system offer to install it in the right place. Analogous to this, a special purpose application could open Settings files for inspection/editing or installation. It would be even easier than a Tracker add-on, as it would just open automatically. Tracker add-ons are for thing you need to do a lot, IMO, and not for occasional tasks.

In the way that I envision setting files, double clicking the icon opens the settings in the corresponding (People-like) pref app. This is why I used the example of an installation Tracker add-on, which would provide the alternative to double-clicking. And since add-ons can be context-sensitive, I am sure it would be possible to just show the "Install this file" add-on when a properly attributed settings file is selected.

Re: Settings, BeOS style

koki wrote:

Maybe I should have said that I liked the IM Kit concept. It may be that the implementation has not been perfected yet, but the concept is very intuitive. The notion of mixing documents with application state is probably one that only affect programmers, and does really not concern end users. For me, being able to keep all contact-related information -- and that includes IM status -- in a single place (the People file) is a real plus and very intuitive.

BTW, why does it bother you so much, when BeOS/Haiku already does this with email files? I mean, the "new/read" state of email files in BeOS/Haiku is stored as an attribute, is it no? :)

I would like the IM contacts to be all virtual, as a classic IM list window or possibly as a filesystem. I don't like applications messing with *my* files, even if it's just attributes.

If I zip up a couple of Email that are read/unread, and move these to another computer, the status attributes are still very much true, and relevant. I have full control. If I zip up the People folder while using the IM Kit, the person files' attributes will reflect the state of those contacts at the time they were zipped, and when unzipped some time later, that state is probably invalid and useless. The attributes, icon colors, etc, will stay invalid untill I run the IM Kit. I'm not in control of my data.

koki wrote:
Jonas wrote:

But we humans can guess.

Does that include humans that cannot code? :P

Of course! Anyone can guess! :)

koki wrote:

Waldemar explains that the same can be achieved by a BMessage, but then that in itself already makes it obscure to the end user. It is the nature of the attribute, which can be viewed directly from Tracker, what would make the content of the setting files easily accessible to the end user.

You need *one unique filetype* (mime string, in the FileTypes database) per *set of attributes* you want to display in Tracker. If there is to be an application to handle opening of preferences, you probably want a single filetype for all settings files, and that means very few attributes. You can't have Tracker showing hundreds of different settings attributes.

BMessage can include other BMessages, nested. You can have trees. Attributes are flat single sets of data. You need to use multiple files and folders and multiple filetypes with different sets of attributes set to be visible in Tracker. It gets really messy and very much complicates life of the preference/application writer. It could be used for very specific settings, like email accounts, but it's not a good idea to try it for all settings.

koki wrote:

In the way that I envision setting files, double clicking the icon opens the settings in the corresponding (People-like) pref app. This is why I used the example of an installation Tracker add-on, which would provide the alternative to double-clicking. And since add-ons can be context-sensitive, I am sure it would be possible to just show the "Install this file" add-on when a properly attributed settings file is selected.

I would much rather have Screen and Background than having to edit those settings as strings in a People-like prefs application. Perhaps I'm misunderstanding your idea.

Re: Settings, BeOS style

Jonas wrote:

If I zip up the People folder while using the IM Kit, the person files' attributes will reflect the state of those contacts at the time they were zipped, and when unzipped some time later, that state is probably invalid and useless. The attributes, icon colors, etc, will stay invalid untill I run the IM Kit. I'm not in control of my data.

How true. I guess this side effect could only be solved if the im_server is always installed and run by default.

Jonas wrote:

I would much rather have Screen and Background than having to edit those settings as strings in a People-like prefs application. Perhaps I'm misunderstanding your idea.

My bad: by People-like app I did not mean that the user would have to enter strings, but that it would open the attribute-based preferences file by double-clicking it (just like it happens with People files), but the app itself could have any control that it would need based on whatever settings it has to set (text fields, combo boxes, lists, checkboxes, etc.).

Jonas wrote:

I'm not talking about the data within the file and the attributes... (snip)

Point taken. But if SkyOS can do it, I would think that it is technically viable in Haiku too (not that I know how to), particularly being that SkyFS is based on OpenBFS. You probably took my (very ignorant) comment that it could possibly be done in Tracker too literally. I actually don't have a clue of how it can be done, but I trust that the someday some Haiku dev will come up with a good way to tackle this in the future. :)

Re: Settings, BeOS style

koki wrote:

if SkyOS can do it, I would think that it is technically viable in Haiku too (not that I know how to), particularly being that SkyFS is based on OpenBFS. You probably took my (very ignorant) comment that it could possibly be done in Tracker too literally. I actually don't have a clue of how it can be done, but I trust that the someday some Haiku dev will come up with a good way to tackle this in the future. :)

Yes it can be done, as proven by a host of operating systems that stack filesystems on top of each other.

There are cases that are likely very reliable, like when you have stacked filesystems that are used in this fashion most of the time, by only one operating system that knows these filesystems intimately. Like on a server.

And you have the Live CD case where a read-only filesystem gets a writable filesystem overlaid, backed by RAM or a USB stick perhaps. This is likely to be reliable too, as the underlying filesystem is not a moving target. The CD filesystem is not likely to change.

But when you have two filesystems stacked on top of each other, say FAT + Haiku Attributes and the underlying filesystem is then used by e.g. Windows for a while, there's a time gap where from a Haiku point-of-view we don't know what happened in the underlying filesystem, and it may be problematic to know for sure that the attribute database is still relevant. Each underlying filesystem type (FAT, NTFS, Ext2, HFS, ..) is likely to be different in what we can know for certain about deleted, moved, resized and renamed filesystem entries (files, folders, links).

I'm just guessing that overlaying attributes on FAT and other filesystems isn't going to be a 100% reliable. I don't think it will be possible to have the attribute mapping follow it's target filesystem entry (usually a file) through all possible changes, on all supported filesystems. So I'm reluctant to commit to the idea. If the filesystem is flaky, applications will be flaky and the user experience will suffer.

IIRC, in some older version of Windows, when you move a folder sometimes it loses the window properties view mode, size and location. I'm guessing each folder's properties were stored in the Registry, and that somehow Explorer failed to update them when you moved folders on disk. But I'm no Windows expert so perhaps I'm all wrong about this. Anyway, analogous to the Explorer issue, correctly analyzed or not, there's no way for Windows to update your (separately stored) attribute database, when files are moved. It doesn't know or care. (And it's not worth the effort of making it aware of BFS attributes on FAT and NTFS.))

One could try to leverage the features of a rich filesystem such as NTFS or Ext3, and try to store BFS attributes -in(side!)- the filesystem, tacked onto the files they belong to as a separate datastream, to make the attributes stay with the file. NTFS should allow this, but it could confuse Windows (or your antivirus software) and other implementations of NTFS, like that in Linux and any other NTFS-capable OS out there. So you have interoperability issues, and you have to test endlessly.

I'm hoping you're right and that these issues can be worked around somehow, or that they are less problematic than I think.

You're probably right about me taking suggested solutions too literally. I think it was Fredrik who suggested that it could be done in Tracker. I apologize to both of you if I came across as Mr No. :] It's just so much easier to explain the problems with a certain solution than it is to suggest a perfect, working solution.

Sorry about the huge reply and all the repetition. :/

Re: Settings, BeOS style

"What if a user moves his preferences files to a FAT volume (any pre-formatted USB stick)? The attributes will be lost."

Let me reply to this one and a couple of more things in this same post that I'd think would "ease" a number of problems.

Regarding the FAT/CDFS/XXXXFS problem, there is a very simple solution to it which most likely would be easy to implement, functional and fast.

Assume Tracker is "file system aware" for a second (I think it is already?). So when moving data/information from a BFS partition to any other partition, why not make it include an "attribute" file, either to the root or to each directory root. If this is done seamlessly by tracker and tracker is aware to look for this very file in each HFS (Hostile File System) when working with it, you could actually use attribute functionality while not using a BFS system. When writing to a CD I would fancy if any burner app would have this "automatic" by the API so that it can write the Attribute file as well. Now this would solve the attribute issue quite easy I believe.

I've always fancied the concept of having an "event daemon" at a later stage. I even believe I've written a draft for it's concept several years ago (under a different nick). Concept here would be store everything from Calendar events to system events just like people files and have them easily queried. That would make transition seamless and would be a very productive way of working. For instance, if you'd at some point actually do productive work, you could save a "todo" file in a folder and have it appear in the event daemon. This way you could easily keep track of stuff. This is extra powerful as normally searching "tasks" in a CRM or Calendar is less powerful than TRacker search query interface (Ehrm.. far less powerful by FAR).

The only real problem with the "file storing" issue I suppose is security/Multi user, but to be honest, at some point I think the whole security thing will be attribute based as well, where users are attributes, and only the right one can access the right stuff. Would also be a "predefined" thing for TRacker queries so you only query what you own/have access to. This would indeed make network settings even more comfortable.

Hope this didn't bore you out =)

Re: Settings, BeOS style

Hai_cu_be wrote:

Regarding the FAT/CDFS/XXXXFS problem, there is a very simple solution to it which most likely would be easy to implement, functional and fast.

Assume Tracker is "file system aware" for a second (I think it is already?). So when moving data/information from a BFS partition to any other partition, why not make it include an "attribute" file, either to the root or to each directory root. If this is done seamlessly by tracker and tracker is aware to look for this very file in each HFS (Hostile File System) when working with it, you could actually use attribute functionality while not using a BFS system. When writing to a CD I would fancy if any burner app would have this "automatic" by the API so that it can write the Attribute file as well. Now this would solve the attribute issue quite easy I believe.

This isn't easy to implement unless you're okay with not seeing these attributes when accessing the "HFS" from BeOS/Haiku applications other than Tracker. BeOS applications don't access file systems through Tracker. Tracker is an application like any other.

The attributes and the files they belong to are likely to get out of sync as soon as the other operating system(s) you may have installed alter the files on the "HFS".

The best we can do for now is to warn the user when copying things from an attributed filesystem to one without. It could be solved at the Haiku filesystem level, so all Haiku applications can see and work with attributes on, e.g., FAT partitions, but that doesn't solve the problem that some other operating system may alter the contents of the volume without updating the Haiku attribute information, and after that it might be impossible to know what file the attribute data belongs to.

Re: Settings, BeOS style

jonas.kirilla wrote:

This isn't easy to implement unless you're okay with not seeing these attributes when accessing the "HFS" from BeOS/Haiku applications other than Tracker. BeOS applications don't access file systems through Tracker. Tracker is an application like any other.

I guess you got me here. On the other hand, the "Open/Save" dialogs might consider what partition you are using and how to handle this issue? Still this might be a problem.

jonas.kirilla wrote:

The attributes and the files they belong to are likely to get out of sync as soon as the other operating system(s) you may have installed alter the files on the "HFS".

That would not be an issue with burning CDs/DVDs/HDVDs/BR I suppose, as this is fixed content. That would be better than nothing

jonas.kirilla wrote:

that doesn't solve the problem that some other operating system may alter the contents of the volume without updating the Haiku attribute information, and after that it might be impossible to know what file the attribute data belongs to.

A bit trickier, and would basically be depending on how you relate the attribute file to whatever is stored. I would imagine filename and time/date to be the link? So if content is updated, time/date will change I guess, and then next time Haiku access the info it might query you to say "seems attributes are out of date, how'd ya like to proceed sir?".

Either way, interoperability is difficult. Everytime we make a new "trade off" we seem to adapt to all other systems and seem to become similar to them. I have to disagree with this direction, I simply don't like it. I like the Attribute thinking, I'd rather see others change. Just like the debate above with the IM-Kit. That's the whole beauty of OSBOS. If you don't like it, then maybe XP is the right choice?

Still, being solution oriented there is obviously more options to this. One is "realtime converter". What do I mean by that?
When copying files from BFS to XXXFS, why not have something similar to a translator which can change stuff on the fly. Like making a music file have it's actual extension for instance. What it also could do is maybe (to whatever formats it applies to) attach attributes inside the file. These are real small as far as I know. Preferably this would be chosen by user in some preferences dialog somwhere.

Loosing the beauty for interoperability in this case is bad... Haiku is a lot about doing what is best isn't it?

Re: Settings, BeOS style -- Transferring data to other disks

MacOS X already has a system in place to aid with transferring data to non-meta-data-aware disks; it creates a ._FILENAME file with all the metadata in it. Why not study and implement a similar solution?

Re: Settings, BeOS style

Jonas wrote:

The attributes and the files they belong to are likely to get out of sync as soon as the other operating system(s) you may have installed alter the files on the "HFS".

This would be true for files that use attributes in addition to data structures that other OSes can understand and modify. I am curious: how many of such file types can you think of?

I mean, if I have MP3 tracks with attributes, and move them to a FAT volume to play them in Windows, I don't see how that can make the BFS attributes out of synch. In the case of people files, well, they are useless outside of a BFS volume, so moving them to a FAT or NTFS partition would be no more than for backup purposes.

What I am getting at is that data coming from Haiku to another OS would most likely be moved there for read-only purposes, so the likelihood of the attributes becoming out of synch, while certainly possible, it is not very likely.

SkyFS (the SkyOS file system) has what they call BranchFS, which transparently adds attribute support to "alien" file systems. Too bad SkyOS is closed source, otherwise this could be a potential source of inspiration to tackle this problem. Being that SkyFS is a fork of OpenBFS, perhaps Robert is gracious enough to return the favor and give the Haiku devs a peek to his code.

Re: Settings, BeOS style

koki wrote:
Jonas wrote:

The attributes and the files they belong to are likely to get out of sync as soon as the other operating system(s) you may have installed alter the files on the "HFS".

This would be true for files that use attributes in addition to data structures that other OSes can understand and modify.

I'm not talking about the data within the file and the attributes. If attributes are not supported, they have to be faked as files, say an extra file called KOKI.DOC.ATTRIBUTES. When you move KOKI.DOC from within Windows, the attributes file stays in the original location, and the next time you run Haiku with that FAT volume Haiku would have to *guess* that the orphaned attributes file in folder A belongs to a file in folder B. A file that may have been renamed, moved, altered in size, checksum, etc. BFS keeps the attributes close to it's file. You can't lose them. In foreign filesystems there are no guarantees.

Re: Settings, BeOS style

Quote:

This isn't easy to implement unless you're okay with not seeing these attributes when accessing the "HFS" from BeOS/Haiku applications other than Tracker. BeOS applications don't access file systems through Tracker. Tracker is an application like any other.

Actually the solution to this problem is adding this capability to the VFS, or to a new layer which sits inbetween the VFS and the Filesystems. Just like SkyOS does.

Re: Settings, BeOS style

jackburton wrote:

Actually the solution to this problem is adding this capability to the VFS, or to a new layer which sits inbetween the VFS and the Filesystems. Just like SkyOS does.

I know. I was talking about the misconception that this capability could be given to all applications simply by extending Tracker.

I'm no expert in filesystems so I could be wrong about this, but I believe that even if this capability was added to the Haiku VFS, there would be no guarantees that the attribute database's -file references- and the actual files on the target filesystem would not deviate from each other, unless you can identify and track files uniquely on all supported filesystems, and the mechanism to do so can be trusted over time, beyond multi booting, filesystem resizing or just plain everyday use.

If the overlaid attributes can't be trusted to never get lost or get lost and then put back on the wrong file, I would be less tempted to build applications that use attributes/indexing/queries as primary mechanisms. BFS attributes are reliable but indexing, in BeOS, has a few issues which complicate the life of an application developer. I wouldn't want to see more unreliability added in this area. I want to be able to trust volumes that say that B_FS_HAS_ATTR and B_FS_HAS_QUERY and know that my application will work well. Of course I already have to make the application aware of capable and incapable filesystems, so perhaps the benefit of having attributes on foreign filesystems outweighs the added burden. Perhaps it's just a shifted burden, where some code to deal with the absence of attributes can be replaced with this new burden of possibly-unreliable attributes.

Re: Settings, BeOS style

I think that there will be a lot of wireless networks to choose from in the future but I don't think there will be that many of them to satisfy the need for the file-approach as you say.

Settings can be in a file and usually is, it would be nice if settings would be in a human readable format but then again how many config file-formats exist in eg. linux :-( ...

Those settings file could have a few attributes, esp. in which Pref app it should opens and