KIO->GnomeVFS bridge started (looking for a Common-VFS)

[Aaron Seigo]

On December 21, 2004 15:52, Thiago Macieira wrote:
> If you choose one implementation, why not stick with it?

hopefully one would ... however:

> Switch to GNOME, but keep KWallet running. If you are switching
> definitely, export your passwords and import them in the new one.

these are actions that would be completely unnecessary if the file format was 
defined. these are also fairly non-trivial actions to take for the average 
user. seeing as this should be completely transparent to the user, i think 
not defining the storage format would weaken the standard.

what's the benefit to not defining the storage format?

one benefit i can see is allowing for things like network storage in LDAP or 
what-not ... but if the format defined is for _local file-based_ storage only 
then that isn't an issue (since an LDAP schema could be added to the spec for 
LDAP, some SQL DDL for RDBMS storage, etc..)

thinking about it further, this really begs the question of service discovery. 
if an application needs the "FD.o wallet" service but no process is providing 
it, which binary is executed? obviously if file formats aren't compatible or 
if concurrent access to the file isn't an option, there needs to be a way to 
say "this is the service to start when the wallet is needed."

 we've solved this in KDE with kded modules to provide on-demand loading of 
services. is there an FD.o standard that provides for something like that? if 
not, that might be an even better place to start.

-- 
Aaron J. Seigo
Society is Geometric
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20041221/82c0caed/attachment.sig>