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:41:20 -0700 (PDT) In-Reply-To: References: <3D60FF7C-95CB-4DB1-9249-D31FE1C9A47D@fastmail.fm> Date: Fri, 1 Apr 2011 10:41:20 -0700 X-Google-Sender-Auth: P3nJDefAgbc1UaGdGhKgGUXVNEY Message-ID: Subject: Re: todo From: Uriel To: 9front@googlegroups.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Apr 1, 2011 at 6:54 AM, Julius Schmidt wrote: >> 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 i= nto >> every server in >> /sys/src/cmd? > > Clients should do it like this: > - send TMove > - get RError back if invalid, then do old style copy and delete, or > =C2=A0move was successful > > One possible problem would be servers crashing on invalid messages. That > would mean they are *really* fucked up and would make it impossible to > use that method. > I would not want our code crash remote servers and a special flag on all > clients to fix that. > (We simply can't fix all the servers out there). No, any sane server will simply kick out and disconnect any client that sends an *invalid* message, Tmove is not part of 9P and is invalid. 9P is not HTTP or some other asstard protocol that is supposed to deal with any magic crap you dump on it, and that is one of the reasons 9P has remained sane and implementing HTTP properly has become an impossible task. The "be liberal with what you accept and conservative with what you send" dogma is the bullshit the web is built on. uriel