[GRASS5] new vector2

[Justin Hickey]

Hi Radim

Radim Blazek wrote:
> Sorry if my thoughts/english was not clear enough.
> (I will use BO = byte order, LE = little endian, BE = big endian)

It's not entirely your fault. My head seems to be in the clouds these
days. :-) 

> Vector files may exist in LE or BE. It is about format
> of vector file more than about how it is created. BO information
> MUST be saved in header because it is the only way how to recognize 
> byte order of the file. The file may be created on BE machine and used
> on LE machine and I don't see any other oportunity how to recognize
> byte order.

OK, the confusion was on my part. I don't know why I didn't see this the
first time.

> New files are files opened by Vect_open_new().
> 
> I think that two rules above together say the same what you want:
> Format is BE or LE + Vect_open_new() opens in native BO = file
> is written in native BO.

Please see below for this one.

> > > - write new module for conversion little <=> big
> > > Conversion module may be used to increase speed if files are not 
> > > in native order.
>
> What is not clear here? User received files created on BE computer but
> he is running LE computer. However he can use that files immediately
> (conversion in memory by library function) he want to increase speed.
> Conversion module may be used for that.

Well, it doesn't really matter. It's just that I was trained to keep low
level functionality (like byte swapping) hidden from users. My idea was
to automatically write out the file in native byte order after reading
it. That way the user sees a one time conversion to native byte order (a
message would indicate the conversion) and gets the increased
performance from then on. The only consideration are network files. In
this case, if the user wants performance he/she will download the file
to the local machine anyway. And if they are already using a network,
then they should be willing to take a performance hit that would be
caused by the conversion, since they are willing to take a performance
hit for the network. Just a suggestion that might save some work.

> Conversion on disk i.e. rewrite file into native BO on the hard disk
> will not be automatic.

Why not? I don't understand why the byte order has to be maintained for
the file. In most cases, since Grass requires a user to own a file to
have write access, then I would expect that user to use a local file.
Also, many users don't even know about the byte order problem. Thus, I
would suggest that the default behaviour would be to always write in
native byte order. If you want to provide the option of writing in
non-native byte order to advanced users, then I would suggest passing an
argument to the pertinent functions. This may be more work than writing
a new module, I don't know, but it somewhat hides the low level
functionality from the user. Again, only a suggestion.

Now a couple of suggestions that you may already know, and I apologize
if that is the case. I saw that XDR maintains byte order regardless of
the machine byte order. Since we are already using XDR, maybe we should
look into using it for the vector format. After all, it is a data
description language. But you may have already considered this.

If we do decide to do our own byte swapping routines, then I suggest we
use a socket function like ntohs() that will do nothing if the byte
order matches or swap the bytes if they don't match. This seems to be
the most efficient method to me. Again, this may be what you were
planning. I just thought I'd mention it.

Please don't take this the wrong way. I'm only trying to understand the
reasons for some of the features you proposed, as well as making some
alternative suggestions that could save people some work.

Talk to you later.

-- 
Sincerely,

Jazzman (a.k.a. Justin Hickey)  e-mail: jhickey at hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand
==================================================================
People who think they know everything are very irritating to those
of us who do.  ---Anonymous

Jazz and Trek Rule!!!
==================================================================

---------------------------------------- 
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'