On 04/10/07 23:28, Glynn Clements wrote:
Moritz Lennert wrote:
So, where should we go from here ? Is it still wiser to implement
readn/writen as you suggest above ?
This is where it gets awkward.
Reading on below it actually seems quite straightforward. ;-)
GRASS uses XDR/RPC for two purposes: libgis uses it for reading and
writing FP raster maps, and DBMI uses it for communication between
the client and driver.
So we should probably thoroughly test libgis' uses of it in windows.
What would be the best way to do this (i.e. in which
circumstances/modules is the xdr part of libgis called) ?
[...]
My preferred approach would be to change lib/db/dbmi_base to simply
not use XDR (that isn't anywhere near as much work as it might
sound).
As the driver and client always run on the same system, it doesn't
matter if the protocol is platform-dependent (I have no idea what
Radim was thinking when he decided to use XDR for the DBMI
communication).
I always had the same question, but (in my ignorance) I thought that it
might make a difference if the actual database was on a different
system. If it doesn't, then let's drop xdr for DBMI (we do really need
it for libgis, I suppose ?).
The dbmi_base library uses the following functions from XDR:
xdr_char xdr_double xdr_float xdr_int xdr_short
xdr_string
xdrstdio_create
The first five all simply read/write the specified value in a fixed
(i.e. non-platform-dependent) format; i.e. convert to big-endian
order, and convert FP values to IEEE format. For DBMI, we can just
use the host's native format, so the first five all amount to calling
read/write on the value.
xdr_string is slightly more complex: read/write the length (including
the terminating NUL) as an unsigned int, followed by the bytes.
xdrstdio_create just sets everything up so that the read/write
operations go through fread/fwrite (as opposed to e.g. xdrmem_create
which sets up for reading/writing from memory).
IOW, the actual implementation of an XDR replacement is trivial. So
trivial that you would just inline most of it into the
db__{send,recv}_* functions.
It's changing the dbmi_base library to use it which will be most of
the work. You would probably want separate put/get functions rather
than the XDR mechanism of setting the "direction" when creating the
XDR object and having a single function for both read and write.
E.g. db__send_int() would change from:
int db__send_int(int n) { XDR xdrs; int stat; stat = DB_OK;
xdr_begin_send (&xdrs); if(!xdr_int (&xdrs, &n)) stat =
DB_PROTOCOL_ERR; xdr_end_send (&xdrs); if (stat == DB_PROTOCOL_ERR)
db_protocol_error(); return stat; }
to something like:
int db__send_int(int n) { int stat = DB_OK; if (!db__send(&n,
sizeof(n))) stat = DB_PROTOCOL_ERR; if (stat == DB_PROTOCOL_ERR)
db_protocol_error(); return stat; }
with db__send() defined as:
int db__send(void *buf, size_t size) { return writen(_send_fd, buf,
size) == size; }
[Actually, you would probably inline writen() here, as this is the
only place it would be used.]
I will need a while understanding this, especially understanding which
files need replacement.
Currently we have the following files in dbmi_base (ls -1 xdr*):
xdr.h
xdr.c
xdrchar.c
xdrcolumn.c
xdrdatetime.c
xdrdouble.c
xdrfloat.c
xdrhandle.c
xdrindex.c
xdrint.c
xdrprocedure.c
xdrshort.c
xdrstring.c
xdrtable.c
xdrtoken.c
xdrvalue.c
of these only the following reference xdr.h ( grep -l xdr.h *.c)
xdr.c
xdrchar.c
xdrdouble.c
xdrfloat.c
xdrint.c
xdrprocedure.c
xdrshort.c
xdrstring.c
xdrchar.c, xdrdouble.c, xdrfloat.c, xdrint.c, xdrshort.c, xdrstring.c
contain the functions you explain how to change above. The only place
where they are called is in the macros.h in the same directory. I
imagine that xdr.c and xdrprocedure.c can just go to the bin.
So "all" we need to do is create new files containing the functions
called in macros.h according to the model you describe above.
What about the other xdr* files which do not actually directly use any
xdr calls (xdrhandle.c, xdrindex.c, xdrtable.c, xdrtoken.c, xdrvalue.c).
Should we just leave them as they are ? Should we rename them to avoid
future confusion ?
Moritz
_______________________________________________
grass-dev mailing list
[email protected]
http://grass.itc.it/mailman/listinfo/grass-dev
