Re: Volume handling proposal

[Ken Deeter <ktdeeter alumni princeton edu>]

Sorry about the last mail. I guess it just a bit too late at night, and
my ssh:// wasn't working ;-)
vs.

> 
> Well, this mail is mostly about the user interface, exactly what VFS is
> used underneath it isn't really the important part, although the
> implementation notes part does use gnome-vfs. If we can agree on the
> behaviour we want for the desktop we can implement that over any VFS
> implementation we want.
>

Yes. At least the discussion on this list should I think strictly stick
to discussing the interface. Maybe I did misread your email, but you did
call it "volume handling" instead of "volume handling UI" ;-)
 
> I'm on the freedesktop project, and there is discussions about a shared
> VFS layer. But I think you severely misjudge the difficulty in doing
> that. Most other freedesktop standards are about file-formats. Here we
> have to share API/ABI, code freeze dates, codebase etc. For the near
> future, gnome-vfs is what we have, so thats what the initial
> implementation will use.
>

I probably do misjudge the difficulty. Is it a difficulty in terms of
technicalities or interms of politics? At the same time, I guess it
feels like saying, well we should never work on the kernel cuz its too
hard to get it right and it doesn't fit the gtk or qt model. I think the
point is that with this kind of thing although it is hard to do, the
benefits likely outweigh the costs.

> 
> You wish! We can't even agree about filesystem semantics between
> different gnome-vfs modules.
>

I was not aware of that. I apologize for over-simplifying the situation.
I guess from the user's point of view (and a programmer who doesn't have much
time to read through the source code, is a user of sorts i guess) its
just typing something into the location bar.
  
> 
> I don't claim that the concept is unique to OS X, that would be stupid
> and irrelevant. But the implementation that is closest to what I
> proposed is in OS X, so its a good thing to refer to.
>

You mean UI implementation right?

> 
> The problem is that to develop stuff you want to use a stack of software
> that makes devlopment easier, and in your model this stack is in the
> [gtk] and [qt..] parts. This means the lower level software is really
> hard to write and integrates poorly with the development stack that
> applications then use.
>

I'm not sure about the 'harder to write' with respect to technical difficulty..
I do agree that its less integrated.. but isn't it usually the case that
a lower level system components don't worry too much about integrating well with the 
applications that sit on top of it? I'm not saying ignore UI concerns
but, I think there is a difference in saying 'let's write GTK well so that
it intergrates well with the system' and 'lets write the system well so
it integrates with GTK'.. sure if the latter is possible its great, but just
beacuse it might not be.. I don't know if its not worth doing then.
 
> The reason this works for i.e. image thumbnails and vfolders is because
> the standard is only about the fileformats, and the code is implemented
> by each desktop in a way that fits their platform. iconv works because
> its a pretty simple API, which don't need much support or integration
> from the runtime. The HAL works because dbus separates the different
> stacks, and each stack has its own dbus integration code, and dbus
> itself painstakenly duplicates a lot of functionallity to avoid
> depending on either stack.
> 

I don't know much about DBUS, but it sounds like another component
object model to me. Could we not use something like this to write a vfs?
or is that too slow?

I thought things like DBUS, Corba, and even CLI work precisely because
the let you concentrate on the API/ABI stuff. Sure there's duplication
among different application architectures, but if there's going to be
something common, there's not getting around that is there? I guess its
just my personal opinion but it seems like where the freedesktop.org
sort of falls short is that there is no shared code projects (well
except for hal) i guess. When I saw what fontconfig could do for
everybody, it only seemed natural that vfs should be done the same way.
Its just that there's no high-profile group to come out and say, we need
a common implementation.. i guess becaus its not clear where this kind
of thing goes (kernel? application stack?) It seems like there are
plenty of libraries that are successfully used by both desktops (fam,
fontconfig, imlib to some extent, xine, mplayer, Xft, cdrecord) and its
almost their saving grace that they didn't build upon either's
application stack. Its unfortunate that just because something isn't
built on gtk or qt, there has to be one done in the other. Maybe DBUS will
finally solve that.

Anyways, sorry, this discussion shouldn't even be happening here.. I'll
try to bring it up in the appropriate place. Maybe it has already
happened in the appropriate place.

> 
> How is it an application? Its just some storage space for files? Thats
> like saying a CD is an application because it has an 'eject' operation.
>

Ok, i just meant that the semantics are different from a 'normal'
storage device, namely in that when you drag a file there, no writing is
actually happening. Although it is a storage device, because of its very
nature you have to interact with it differently, and so I think making
an abstraction so that in the file manager they look exactly the same
might make it a bit confusing.

Someone might say, "well in fonts:// i can just drop things in and it
goes, so why can't I in burn://?" Don't get me wrong, I do like the interface
for cd burning htat burn:// provides, but to think of it as exactly the
same thing as a directory seems like a bit of strech to me.

I think its telling that its "burn", which is a verb, where as things
like "computer" "network" "file" are all nouns.

CD-RW's in packet writing mode on the other hand..
 
> > it would be the same if we had printer:// or something, we would need buttons
> > probably for 'delete job' 'change prioriy' etc. etc... I'm all for making
> > these things heavily re-use nautilus components, but it may be much to try
> > to force them into a filesystem concept.
> 
> I agree with this, i don't think printers should be exposed like this,
> but some people do.
> 
> I really think you misread my email. It is not about reimplementing
> anything. Its about designing a coherent user interface that ties
> together all the different parts we already have in Gnome in a way that
> users can understand.
>

I probably did, and I apologize for that. It just seemed that on top of
discussing UI, you were talking about how to do vfs things, and that you
were implying a direction that might make things not much better than
they currently are, and at least as someone who switches between kde and
gnome every week.. the vfs situation isn't that pretty.

------

 +----------------------------------------------+
(  Ken Deeter (Kentarou SHINOHARA)             (
 )                                              )
(  "If only God were alive to see this.. "     (
 )                             -Homer Simpson   )
+----------------------------------------------+