Re: todo

[Uriel <uriel@berlinblue.org>]

I don't really have time for this bullshit discussion, but:

> A special extra file to do a special operation (which move really ought not to be) breaks unity and consistency.

This is a load of total crap, precisely using an alternative attach
name *preserves* the unity and consistency of the current protocol,
because instead of having an extra special magic protocol message, you
just use read() and write(), Tmove does not apply to most file systems
and there are very good reasons it was not part of the protocol
already.

Crap like Tmove is stuck in the 'files are just for storage' mindset,
instead of the 'the file system is the universal API'.

Also, any 'flakery' that applies to an alternative attach name applies
to Tmove, because you still need to make the right interpretation of
the target path, etc.

And changing the protocol will break fucking *everything* (and a few
more things), we went over this shit with .u, it was a disgrace that
split the 9P world in two and further damaged the 'consistency' and
'unity' of the 9P world.

In short: stop this fucking madness already.

uriel


On Fri, Apr 1, 2011 at 6:36 AM, Ethan Grammatikidis <eekee57@fastmail.fm> wrote:
>
> On 1 Apr 2011, at 12:38 pm, cinap_lenrek@gmx.de wrote:
>
> maybe we can live with a special fscmd and let the user figure out
> the right filsys name and path? we can make the command format
> and naming compatible so it works consistently with kfs, cwfs and
> kenfs.
>
> This sounds like it could be a bitch if it's 2 in the morning and you just
> want to move those few videos you just downloaded to their proper place
> before going to sleep.
>
> From: Uriel <uriel@berlinblue.org>
>
> Changing the protocol for this is just stupid, next you will find a
> trillion equally good reasons to add other extensions.
>
> Ah, the time-honoured argument against change. :] Move is not just any
> extension. It doesn't exist for some flaky transient piece of bullshit
> software that will be forgotten in 5 years time. It exists because storage
> space has grown faster than storage speed. Not just space, storage use has
> grown faster than the speed.
> Then there's the idea of a unified interface to your files. A special extra
> file to do a special operation (which move really ought not to be) breaks
> unity and consistency. mv is one of the fundamental file operations, and I
> for one REALLY don't want it trying to find some 3rd file to send messages
> to... That's got to be flakey at best, hasn't it? Also it kinda reeks of
> .git / .hg. If you're working in a subdir of a git repo, git very graciously
> looks up the tree until it finds .git, but if you try to include one git
> repo inside another it breaks.
> There's another thing: How _hard_ will Tmove break anything? How much
> trouble will it be to fix everything to fail gracefully, either for any bad
> message or just for Tmove (whichever is easier)? Granted, "old software"
> isn't necessarily included in "everything" but how much work will it be to
> find and look into every server in /sys/src/cmd?