Re: superlifter design notes (OpenVMS perspective)

2002-07-30 Thread jw schultz
On Tue, Jul 30, 2002 at 12:00:21AM -0400, John E. Malmberg wrote: To help explain why the backup and file distribution have such different implementation issues, let me give some background. This is a dump of an OpenVMS native text file. This is the format that virtually all text

Re: superlifter design notes (OpenVMS perspective)

2002-07-28 Thread Ben Escoto
JS == jw schultz [EMAIL PROTECTED] wrote the following on Sat, 27 Jul 2002 23:05:50 -0700 JS As a poor example let us suppose that a filename contained a JS /. A UNIX system using translation might turn this into _. JS Escapement might turn it into =2F and = into =3D. rdiff-backup has

Re: superlifter design notes (OpenVMS perspective)

2002-07-28 Thread Martin Pool
On 27 Jul 2002, jw schultz [EMAIL PROTECTED] wrote: The server has no need to deal with cleint limitations. I am saying that the protocol would make the bare minimum of limitatons (null termination, no nulls in names). It probably also makes sense to follow NFS4 in representing paths as a

Re: superlifter design notes (OpenVMS perspective)

2002-07-28 Thread jw schultz
On Sun, Jul 28, 2002 at 05:39:22PM +1000, Martin Pool wrote: On 27 Jul 2002, jw schultz [EMAIL PROTECTED] wrote: The server has no need to deal with cleint limitations. I am saying that the protocol would make the bare minimum of limitatons (null termination, no nulls in names). It

Re: superlifter design notes (OpenVMS perspective)

2002-07-27 Thread John E. Malmberg
Lenny Foner [EMAIL PROTECTED] wrote: jw schultz wrote: I find the use of funny chars (including space) in filenames offensive but we need to deal with internationalizations and sheer stupidity. Regardless of what you think about them, MacOS comes with pathnames containing spaces

Re: superlifter design notes (OpenVMS perspective)

2002-07-27 Thread John E. Malmberg
Martin Pool wrote: On 22 Jul 2002, John E. Malmberg [EMAIL PROTECTED] wrote: A clean design allows optimization to be done by the compiler, and tight optimization should be driven by profiling tools. Right. So, for example, glib has a very smart assembly ntohl() and LZO is tight

Re: superlifter design notes (OpenVMS perspective)

2002-07-21 Thread John E. Malmberg
Qualities 1. Be reasonably portable: at least in principle, it should be possible to port to Windows, OS X, and various Unixes without major changes. In general, I would like to see OpenVMS in that list. Principles 1. Clean design rather than micro-optimization. A clean design

Re: superlifter design notes (OpenVMS perspective)

2002-07-21 Thread Martin Pool
On 22 Jul 2002, John E. Malmberg [EMAIL PROTECTED] wrote: Qualities 1. Be reasonably portable: at least in principle, it should be possible to port to Windows, OS X, and various Unixes without major changes. In general, I would like to see OpenVMS in that list. Yes, OpenVMS, perhaps

Re: superlifter design notes (OpenVMS perspective)

2002-07-21 Thread Martin Pool
User-Agent: Mozilla/5.0 (X11; U; OpenVMS COMPAQ_AlphaServer_DS10_466_MHz; en-US; rv:1.1a) Gecko/20020614 If something as complex as Mozilla can run on OpenVMS then I guess we really have no excuse :-) -- Martin -- To unsubscribe or change options:

Re: superlifter design notes (OpenVMS perspective)

2002-07-21 Thread jw schultz
On Mon, Jul 22, 2002 at 03:34:37PM +1000, Martin Pool wrote: On 22 Jul 2002, John E. Malmberg [EMAIL PROTECTED] wrote: If you structure the protocol processing where no subroutine ever posts a write and then waits for a read, you can set up a library that can be used either blocking