Re: App control of linc/link part of ORBit2

[Jan Kratochvil <rcpt-orbit-list AT gnome org jankratochvil net>]

Hi Michael,

This mail may is more Gnome-VFS specific although it started at ORBit.

On Mon, 10 Nov 2003 11:40:19 +0100, Michael Meeks wrote:
> On Fri, 2003-11-07 at 06:31, Jan Kratochvil wrote:
...
> 	I don't know if you're going to be using this architecture long-term;
> it certainly looks interesting.

I expect the http://linux-ntfs.sf.net/ GPL NTFS implementation does not get its
access read/write and by safe way for the following several years.
Therefore I am going to maintain my ntfs.sys emulation approach where
ORBit2/Gnome-VFS is its essential part.


> If you grab the latest HEAD gnome-vfs,
> libbonobo, ORBit2 you'll see that we now have a 'Daemon' interface that
> allows the full Stream API to be pulled out of process.

The primary disadvantage of using this Gnome API is its limitation to the
common API set - all filesystems API intersection. I was evaluating the use of
Moniker as filesystem ORBit API a year ago. Finally I withdrew using even
GnomeVFSMethod API as the primary communication channel as I need various
MS-Windows specific and emulation specific (ORBit device access, message
logging) filesystem API extensions.
	http://www.jankratochvil.net/project/captive/doc/dia/arch-all.png

These extensions can be implemented by GnomeVFSMethodFileControlFunc but I even
did not found appropriate peer for it at Moniker/Daemon. I used ORBit2 as the
easy enough way to reach my RPC separation needs to be able to focus on
MS-Windows NT kernel disassembly/debugging and deploy the project in time.

Unification to Gnome filesystem API while implementing the nonstandard calls by
some other way would not be clear enough and it would increase the development
costs for me. There may be a way to interface GnomeVFSMethodFileControlFunc
by requirement for its parameters GLib marshaller and transferring the
resulting GValue parameters by ORBit.


> 	There are several things that'd be great to have done in there, but
> just having some more review of the API might help; and/or working out
> if we could make it such that you could plug your stuff into a stock
> GnomeVFS install without modifications.

I already provide Gnome-VFS module interface usable by syntax
	file:///dev/hda1#captive-ntfs:autoexec.bat

but it is provided only as the external NTFS interface; project uses its own
MS-Windows emulation specific custom ORBit API for the reasons above.

While you already provide a rich filesystem subsystem by Gnome I still miss
there the goal of platform-specific interfaces for legacy OS applications.
I ported UserVFS to use Gnome-VFS but it was dropped by Alexander Larsson:
	http://mail.gnome.org/archives/gnome-vfs-list/2003-February/msg00066.html

Currently there is already available 'gvfs' module to access Gnome-VFS by LUFS
(Linux Userland File System):
	http://lufs.sf.net/lufs/

Your proposal:
NTFS Gnome-VFS module <-> Gnome-VFS Daemon <-> Gnome application
                                            \- LUFS <-> kernel <-> legacy app
Current scheme:
NTFS LUFS module <-> LUFS <-> kernel <-> Gnome application
                                      \- legacy application

I do not care much about this difference although it gets GNU/Linux specific
this way.



Regards,
Lace

-- 
Jan Kratochvil; Captive: free r/w NTFS Filesystem; http://www.jankratochvil.net/