[*nix] FreeDesktop specification adherence?

Talk about code development, features, specific bugs, enhancements, patches, and similar things.
Forum rules
Please keep everything here strictly on-topic.
This board is meant for Pale Moon source code development related subjects only like code snippets, patches, specific bugs, git, the repositories, etc.

This is not for tech support! Please do not post tech support questions in the "Development" board!
Please make sure not to use this board for support questions. Please post issues with specific websites, extensions, etc. in the relevant boards for those topics.

Please keep things on-topic as this forum will be used for reference for Pale Moon development. Expect topics that aren't relevant as such to be moved or deleted.
Axiomatic

[*nix] FreeDesktop specification adherence?

Unread post by Axiomatic » 2015-09-23, 16:24

Hello,
I realize http://forum.palemoon.org/viewtopic.php?f=37&t=6814 address most of my question. However since it is locked I cannot discuss the matter.

FreeDesktop published the XDG Base Directory Specification which states where a program should store user data, and configurations. Currently both, Firefox, and Pale Moon do not adhere to the specification of storing user data, and configurations. Does anyone else from the Linux/*nix background disagree with the specification? If possibly please explain why. (Since Moonchild said: "I'm not saying it's a definite no-go" (see above topic link) we probably have a chance to get Pale Moon XDG base directory specification compliant.)

There is a BMO bug #259356 would be nice to merge into the master branch of Pale Moon before v26 (or v27 I cannot estimate the complexity yet, since I do not plan to take the patch directly, since there should be some modification to discuss hopefully in this thread.)

An issue that come from the BMO bug, that we should likely talk about:
Distinction between cache, data, and configuration. (Currently pretty much everything is inside, ~/.moonchild\ productions (side note, do we want to keep the 'm', and the 'p' lowercase, or follow the style on Windows?)

My first thought:
On certain distros the XDG cache location symlinks to /tmp which is not quite what users may want. (I speak specifically about those who wish cache persists through the browsing session, and the next, and the next and so on and so forth, until they decide to clear out their cache. (Though speaking from my experience, there is no option in Pale Moon that preserves cache in such a manner, it is just a byproduct of where cache is currently stored.))

Remember please keep the discussion civil.

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 35476
Joined: 2011-08-28, 17:27
Location: Motala, SE
Contact:

Re: [*nix] FreeDesktop specification adherence?

Unread post by Moonchild » 2015-09-23, 21:54

The distinction between cache, config and data is difficult. It looks nice on paper but in practice there are no such hard lines in Pale Moon to draw.

Your example of cache on some distros being stored in /tmp -- that would make using a persistent disk cache absolutely useless because it would be thrown away after a session. So, that already makes cache something you don't want to store in cache, then.

Another example would be certificates. Is the certificate store configuration or data? Arguments can be made either way.
And preferences, is that configuration or data? Config? Are you sure? What about people having an extensive list of domain-specific UA overrides -- how is that easy to reconfigure or less of a "data" type than bookmarks?

So it's easy to see that making a distinction between config and data, at the very least, depends on use cases and individual workflow. I wouldn't just want to take the patch that dumps everything in ~/.config because there's a lot of profile data that is actual roaming data and not machine-specific configurations.

It's just a lot less complex for both the user and the browser to have a single, distinct application data directory under $HOME where everything is stored. It reduces the overall "spread all application data everywhere" that is usually the cause of many many headaches (some Windows applications suffer from this too and makes it extremely difficult to handle when anything on the file system changes or to even make a usable backup)

If we somehow want to adhere to this Base Directory Specification, then the first thing that needs to happen is getting consensus about what is cache (and avoiding using a volatile location for disk cache), what is config, and what is data.
It also needs different Linux distros to handle the XDG Base Directories uniformly, because it's not possible for a cross-platform browser to use more than one type of data storage for one specific class of OS. As long as Linux/UNIX/BSD distros can't agree on how cache, data and config are handled, there's really no point in starting to implement it on the application side and taking big risks of data loss and lots of confusion for end users.
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite

New Tobin Paradigm

Re: [*nix] FreeDesktop specification adherence?

Unread post by New Tobin Paradigm » 2015-09-23, 22:05

I would be completely opposed to this for the simple fact that I in the past and undoubtedly will again in the future will want profile portability between Windows and Linux.

I already treat my Pale Moon profile (and a lot of appdata in general) as platform and specific install independent. It lives on another drive and in most cases (though not with Pale Moon because I can use profile manager to direct it to the proper folder) symlinked into the default place.

This method has been standard practice since the virtual inception of our codebase and I would not take kindly to this kind of change just to satisfy some arbitrary linux standard that half the time linux programs or operating systems them selves ignore.

IF this did happen.. I would have to either revert the patch for a private install or symlink things BACK to standard Mozilla profile configuration manually adding a bunch of unnecessary work for little gain.

Frankly, I find how it is done now SHOULD be the standard for how all programs store their unique appdata.. Strictly in a self contained appdata folder for that program and things kept on a file based level. This linux notion of pieces spread all over the place has NEVER been something personally liked and where possible in my own systems have attempted to mitigate through my own structure and well placed symlinks.

Supernova

Re: [*nix] FreeDesktop specification adherence?

Unread post by Supernova » 2015-09-24, 09:27

Agreed with Tobin, the spread of program data all over the place is something which drives me nuts when I need to find a particular data or to make a backup.
Configuration is data.
Cache is data.
It's just a particular kind of data.

Tharn

Re: [*nix] FreeDesktop specification adherence?

Unread post by Tharn » 2015-09-24, 09:55

There's several folders in the user directory. ~/.config, ~/.local and ~/.cache. I think these resemble Roaming, Local and Temp folders, respectively, and should fit the bill for Palemoon. I wouldn't use /tmp. Palemoon cache aren't leftover files, they're possibly sensible (identifying) bits belonging to a certain user account, and that's where they belong. Vested interest here being that I have an encrypted /home partition, but /tmp is just part of the unencrypted root partition. It makes sense like that.

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 35476
Joined: 2011-08-28, 17:27
Location: Motala, SE
Contact:

Re: [*nix] FreeDesktop specification adherence?

Unread post by Moonchild » 2015-09-24, 12:04

Tharn wrote:There's several folders in the user directory. ~/.config, ~/.local and ~/.cache. I think these resemble Roaming, Local and Temp folders, respectively, and should fit the bill for Palemoon. I wouldn't use /tmp. Palemoon cache aren't leftover files, they're possibly sensible (identifying) bits belonging to a certain user account, and that's where they belong. Vested interest here being that I have an encrypted /home partition, but /tmp is just part of the unencrypted root partition. It makes sense like that.
It's not how Pale Moon stores data. The disk cache is not stored in %TEMP% on Windows, for example, and is persistent data that is user-specific - on Windows, it's stored in Local under the user account. Using ~/.cache for that would be incorrect.
Configuration isn't stored in Local, but in Roaming, so it's considered data on Windows (everything but update files and cache is stored in the profile in Roaming, and should not be split out in different locations). So all it would do is dump everything that is now in ~/.moonchild productions/ into a different folder under a different HOME that may not even be in the user's home dir, may be subject to filesystem restrictions not encountered in $HOME and is a real headache to set up since it also requires one to allow for a whole list of locations where data may be stored. Why would I want to add that level of complexity to Pale Moon?

Looking at the latest spec there are clear pointers that to adhere to the spec, app default configuration (which is stored in the application binary folder at this time) should be moved to /etc/xdg/* somewhere, as well. This would work if that is the normal MO for an application (basically *nix-specific system/user applications), but for Pale Moon it is not. It expects its internal default confgurations to be contained within the application itself.
It also states nothing about what to do when files are found in multiple stated locations, only that "a specification referring to the XDG BDS should define what the behavior must be when a file is located under multiple base directories". The spec is completely ambiguous and intended for other specs to refer to it.

I'd prefer to KISS it: keep all data in the app specific folder under $HOME and nowhere else. We don't have to scan other locations in the system, users don't have to know where all everything gets stored, backups are easy and it remains relatively portable for e.g. network sharing or remote profile storage.
Wasn't the whole idea of having individual user HOME dirs so that it would all be user-profile contained in the first place?

All of this may work if you design a new application that is *nix specific and that can use this kind of setup, but I just don't see it working for Pale Moon.
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite

half-moon

Re: [*nix] FreeDesktop specification adherence?

Unread post by half-moon » 2015-09-25, 14:05

Plus, how would you be able to comply with this standard for the Windows version? My guess is that you couldn't, but I could be wrong. It probably is just best to keep things the way they are.

Tharn

Re: [*nix] FreeDesktop specification adherence?

Unread post by Tharn » 2015-09-25, 16:56

You couldn't, because it pertains only to Linux. Anyway, it's a 'would be nice', but it's not like Palemoon is the only program that doesn't adhere to the XDG guideline. Some Linux apps don't, either.

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 35476
Joined: 2011-08-28, 17:27
Location: Motala, SE
Contact:

Re: [*nix] FreeDesktop specification adherence?

Unread post by Moonchild » 2015-09-26, 22:17

Tharn wrote:You couldn't, because it pertains only to Linux.
Which is where part of the problem is -- Pale Moon is cross-platform.
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite

Locked