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

[Tomi Manninen]

On Fri, 4 Jan 2002, WILLIAMS,TED (HP-NewJersey,ex2) wrote:

> Been away for a while, but I'm back.

Me too.

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

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

I'm not necessarily saying that a struct is not a good way to do it, it 
would just have to be well thought out.

> Now, who wants to convince me that the data is being passed in the right
> direction.
> I still prefer the log program passing the data to the app.  HI

Well, I think I was the one who requested the feature from Joop so I can 
share my view. My gmfsk program has had the call/name/qth/rst etc. 
entry fields from day one and I always thought they are a must. As one of 
my beta testers said it: "if your program doesn't have good macros for 
automating the qso as much as possible, I won't probably ever have a qso 
with it... :-)"

I think the name/qth etc. macros are rather necessary for a program like
this (but then again I work very little and have had only a couple of qsos
even with gmfsk myself so I may not know what I'm talking about). Anyway 
I didn't want to make gmfsk dependent on any external program and there 
really wasn't any good log programs I was aware of then.

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

-- 
Tomi Manninen           Internet:  address@hidden
OH2BNS                  AX.25:     address@hidden
KP20ME04                Amprnet:   address@hidden