Re: [Xlog-discussion] RE: Hold your (xlog-) horses - suggestion

[Stephane Fillod]

On Mon, Jan 07, 2002, Tomi Manninen wrote:
> > As for:
> > > version:1\1program:gmfsk\1date:17 Nov
> > 2001\1time:1200\1call:PA0DIN\1name:din
> 
> Joop, wouldn't '\n' serve as a bit more natural field separator? Just a 
> thought...

Yes, this may be more natural, but this would prevent some fields like the
comment being on multiple lines.
So, why not using '\0' one would say?
Well, because there's this damn glib g_strsplit function that reserves the
'\0' for the end of the string. After all, it's just about aesthetic, and
I'm pretty sure '\1' will do the job as well :)

> > Here is something you may want to think about for passing this data.
> > Instead
> > of passing the message data a string, why not pass it as a struct? (type
> > cast as 
> > needed)  That should make retrieving the data fields a lot easier.  
> 
> Well, with structs there is always the problem of compatibility and
> flexibility. We obviously don't have any architecture problems, but I 
> think things like alignment can be affected by the compiler flags (not 
> sure though).
>
> Also as the transferred data will in any case be extended at some point, 
> we need to be careful about how different versions of the struct are 
> handled.

Totally agree with you.

> I never meant to implement any log features to gmfsk and never will. The
> original idea was to implement exporting the qso data in ADIF format to
> some file which could then be imported into a real log program.
> 
> With the above, app -> log program is the natural direction for the data 
> to go. However I don't see why xlog couldn't also export the data in 
> shared memory to other apps...

IMHO, app -> log is the way to go. 
One task to add to the xlog todo list is the ADIF import/export,
and I volunteer, once the "flexible" text format is done.
(http://www.hosenose.com/adif/adif.html).

73,
Stephane F8CFE