[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xlog-discussion] RE: Hold your (xlog-) horses - suggestion
From: |
Joop Stakenborg |
Subject: |
Re: [Xlog-discussion] RE: Hold your (xlog-) horses - suggestion |
Date: |
Mon, 7 Jan 2002 22:17:41 +0100 |
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