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

[Joop Stakenborg]

On Mon, 7 Jan 2002 19:34:22 +0200 (EET)
Tomi Manninen <address@hidden> wrote:

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

Sure! Sounds reasonable.
Tomi, just edit xlog to your needs and send me the patch.
It's easy enough to release a minor version (0.5.1) for
xlog, once you get things going with gmfsk.

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

I would like to stick with the current message format.
While it will certainly not be the most handsome way of programming,
I like the flexibility we have now.

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

Haa! I should have thought if this. This way both Ted and Tomi will
be happy. I will have a look at Ted's twlog to see how he did it.

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

Thanks for your comments,

Joop PA4TU