Mailinglist Archive: opensuse-features (194 mails)

< Previous Next >
[openFATE 310515] Filesystem compatybility layer
  • From: fate_noreply@xxxxxxx
  • Date: Mon, 20 Sep 2010 13:29:38 +0200 (CEST)
  • Message-id: <feature-310515-3@xxxxxxxxxxxxxx>
Feature changed by: Tim Edwards (tk83)
Feature #310515, revision 3
Title: Filesystem compatybility layer

openSUSE-11.4: Unconfirmed
Priority
Requester: Neutral

Requested by: Sławomir Lach (lachu)
Partner organization: openSUSE.org

Description:
Many closed source software are designed to working with only one
operating system. Main  problem to creating closed source application
to Unix is filesystem hierarchy difference.
 
We can fix that by using package manager. First of all, RPM's should
provide variables for some predefined path, like program data(such like
levels), program icons, wallpapers, system-wide configuration, program
configuration, etc. There's should exist an library to ask for one of
them. It is very similar to XDG_DESKTOP_PATH specification, but much
wider.
 
Second off all we should create /application directory(such like proc)
and mount there virtual file system containing links to application
resources(in hierarchy defined by package). Mount process would been
performed on special library initialization, so application should use
special library to be independent.
We can also allow to publish some other information into /application,
such like named fifo, new run locking system, etc.
/application/pid/resources could contains for example files(name fifo)
to be shared between application and another.

Test Case:
Create OpenSource application, which uses this library. Create a lot of
packages without recombiling(one binary file).

Use Case:
Developer would create closed source application, but filesystem
hierarchy difference in each system is too big matter for him.
He create his own hiearchy and tell to packagers: do rest of work.

Business case (Partner benefit):
openSUSE.org: Filesystem hierarchy differences are too big matter for
developers. We can solve this problem with delivering code source to
packagers, but that's no solution for closed source programmers.
Imagine developer would prepare application for MacOS X and Linux.
Without making rubbish(like in Solaris, which supports many of
standards) we can't provide better solution than mine( ;-) ). Developer
will compile library with our new Virtual File System library(or
better: library providing special interface to asking for information
about application virtual filesystem). Actually it works in this way:
file system hierarchy should been fully transparent for user and
application will only acts with it. In my opinion, it's impossible. So
makes it different: File System Hierarchy are for administrators, not
for applications. User will still don't care about it(it haves /home
directory).

Discussion:
#1: Jan Engelhardt (jengelh) (2010-09-19 17:11:27)
>Developer will compile library with our new Virtual File System
library
This reads like legalese, so I respond in legalese: Developer will not.
I see no compelling reason to do anything like this. Especially since
there _is_ already, for example, libgnome-vfs2. I don't see why one
should use your library over that.

+ #2: Tim Edwards (tk83) (2010-09-20 13:29:27)
+ The difficulties with porting programs from one OS to another go a lot
+ deeper than the filesystem layout. Not to mention that a virtual
+ filesystem layout that presumably mimicked Windows' or OSX's and
+ somehow 'translated' paths onto a Linux layout would be a massive
+ undertaking, if not impractical.



--
openSUSE Feature:
https://features.opensuse.org/310515

< Previous Next >
List Navigation