volatile config data and XDG Base Directory spec

[Kevin Krammer]

On Saturday, 2014-02-22, 22:14:50, Thomas Koch wrote:

> On Wednesday, February 19, 2014 01:40:39 PM Simon McVittie wrote:
> > On 18/02/14 23:53, Richard Hartmann wrote:
> > 
> > the difference between DATA and STATE appears to be "STATE doesn't
> > contain much data, and doesn't need to be sync'd across machines". But
> > surely if it's small, it doesn't matter if it gets sync'd across
> > machines unnecessarily? If an application wants to store explicitly
> > per-machine state, it can use the D-Bus/systemd machine ID as a key,
> > like GNOME does for display settings (I know that's config rather than
> > state, but the principle is the same).
> 
> Well, you're pinpointing it. Syncing window positions or recently opened
> files across machines would lead to undesired behaviour because different
> machines have different screen setups and differnt sets of files. You put
> the burden on the application developer to distinguish between machines,
> but that's unrealistic. The xdg-basedir-spec should rather help by
> providing a directory for state information that makes sense only in the
> context of this machine.

Sorry, slighly offtopic, but:

Window geometry is a rather bad example for a machine specific state, since it 
is screen setup specific.

Either application developers really want the burden of handling that 
themselves, in which case they need to track screen configurations somehow, or 
they do the sensible thing and let the workspace shell/window manager handle 
it for them.

My rather limited knowlegde around Wayland even suggests, that the latter will 
be the only option there anyway.

Cheers,
Kevin
-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/xdg/attachments/20140224/eee2e5c9/attachment.pgp>