Developer will compile library with our new Virtual File System
Feature changed by: Robert Davies (robopensuse) Feature #310515, revision 5 Title: Filesystem compatybility layer openSUSE-11.4: Rejected by Thomas Schmidt (digitaltomm) reject reason: Seems there is no support from someone implementing this. 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) 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. + #3: Robert Davies (robopensuse) (2011-02-02 09:31:23) + "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." + This core assumption is simply not true, generally a Windows or Java + API is what they code to and WINE & java are big projects in their own + right, not something solved by a distro. + There's been quite a number of API's (and included with SuSE) featuring + compatability between Windows & Linux, how many 'dows programs have you + heard of using them? + Even when programs are basically portable, business managers of + software do not want to market to minority nor open themselves up to + support risks on other OS, which might require staff re-training. -- openSUSE Feature: https://features.opensuse.org/310515