From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 Sender: lost.goblin@gmail.com Received: by 10.236.108.44 with HTTP; Fri, 1 Apr 2011 10:38:22 -0700 (PDT) In-Reply-To: <3D60FF7C-95CB-4DB1-9249-D31FE1C9A47D@fastmail.fm> References: <3D60FF7C-95CB-4DB1-9249-D31FE1C9A47D@fastmail.fm> Date: Fri, 1 Apr 2011 10:38:22 -0700 X-Google-Sender-Auth: bJdjaQHuhLApFln_QR5E3HxBACk Message-ID: Subject: Re: todo From: Uriel To: 9front@googlegroups.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I don't really have time for this bullshit discussion, but: > A special extra file to do a special operation (which move really ought n= ot 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 w= rote: > > 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 jus= t > want to move those few videos you just downloaded to their proper place > before going to sleep. > > From:=C2=A0Uriel > > 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 storag= e > space has grown faster than storage speed. Not just space, storage use ha= s > grown faster than the speed. > Then there's the idea of a unified interface to your files. A special ext= ra > 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 message= s > 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 graciou= sly > 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 b= ad > message or just for Tmove (whichever is easier)? Granted, "old software" > isn't necessarily included in "everything" but how much work will it be t= o > find and look into every server in /sys/src/cmd?