RE: Issues list for RFC3010

New Message Reply About this list Date view Thread view Subject view Author view Attachment view

From: Noveck, Dave (Dave.Noveck@netapp.com)
Date: 09/20/01-02:53:51 PM Z


Message-ID: <8C610D86AF6CD4119C9800B0D0499E33335612@red.nane.netapp.com>
From: "Noveck, Dave" <Dave.Noveck@netapp.com>
Subject: RE: Issues list for RFC3010
Date: Thu, 20 Sep 2001 12:53:51 -0700

Spencer Shepler wrote: 
> On Thu, Sergey Klyushin wrote:
> > >Issue08:
> > >Change of "tag" in COMPOUND4args. At a minimum the server should return the
> > same tag length/contents that were >included in the request. Alternate
> > changes are: fixed length tag or no tag at all.
> > 
> > I vote to remove "tag" at all. If it used for debugging - use snoop, if it
> > used for caching - use something else (xids from RPC)
> 
> Well, I have found that in using snoop it is really nice to have a tag
> string to give you some indication of what the client is attempting to
> accomplish with the string of COMPOUND operations.
> 
> My personal preference would be to have a fixed length string.  We
> could even make it a regular xdr string type to avoid the utf8
> "overhead".

What overhead?

If all the characters are pure ASCII, there is no overhead to UTF-8.

Characters between 128-255 require an extra byte.

Characters between 256-2047 require two bytes in UTF-8 but they would
in any encoding.

Characters bewteen 2048-65535 require an extra byte.

So are you planning tags that have characters 128-255 or 2048-65535?
I know the latter wouldn't help me too much, even if snoop were to
print them out.

If we are going to have string tags it seems awfully provincial
not to allow the full range of UCS characters.  

 


New Message Reply About this list Date view Thread view Subject view Author view Attachment view

This archive was generated by hypermail 2.1.2 : 03/04/05-01:49:07 AM Z CST