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-29 Thread John E. Malmberg
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 editors produce on it. Dump of file PROJECT_ROOT:[rsync_vms]CHECKSUM.C_VMS;1

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). >

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

Re: superlifter design notes (OpenVMS perspective)

2002-07-27 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

Re: superlifter design notes (OpenVMS perspective)

2002-07-27 Thread jw schultz
On Sat, Jul 27, 2002 at 02:50:52PM -0400, John E. Malmberg wrote: > 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. > > > >Regardles

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 >

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 sp

superlifter design notes (OpenVMS perspective)

2002-07-22 Thread Lenny Foner
Date: Sun, 21 Jul 2002 23:06:23 -0700 From: jw schultz <[EMAIL PROTECTED]> I find the use of funny chars (including space) in filenames offensive but we need to deal with internationalizations and sheer stupidity. Regard

Re: superlifter design notes (OpenVMS perspective)

2002-07-21 Thread jw schultz
On Mon, Jul 22, 2002 at 04:31:51PM +1000, Martin Pool wrote: > On 21 Jul 2002, jw schultz <[EMAIL PROTECTED]> wrote: > > > That is the better approach. Use I/O routines so most > > processing can be "while (get_input()) { process(); send_output()}" > > Then the I/O routines can be defined accori

Re: superlifter design notes (OpenVMS perspective)

2002-07-21 Thread Martin Pool
On 21 Jul 2002, jw schultz <[EMAIL PROTECTED]> wrote: > That is the better approach. Use I/O routines so most > processing can be "while (get_input()) { process(); send_output()}" > Then the I/O routines can be defined accorinding to platform. while 1: examine fd if input available:

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 eithe

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: http://lists.samba.org/mailman/listinfo/

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, O

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