[Xlog-discussion] Re: logging

[Joop Stakenborg]

<address@hidden> wrote:
> 
> Hi Joop,
> 
> Thanks for the info.  You have a good idea.  We should agree on a common way
> to pass info between related applications.  I wasn't aware that you and
> others were implementing it, so this was just my approach, and of course, 
> one of may ways. I may not understand what you mean by remote logging.  
> 
> As for the way I do it, here are some things I considered.
> 
> For the GUI user, the Call box on the log program seems to be the most
> intuitive place to enter the call sign.  You always enter the call
> in the same place in the same way, and the log program "publishes" 
> it for whatever programs want it.  
> 

I like the idea. However, the program which is used for making a QSO will
always have focus. With your approach, the user will have to click on the
twlog window, so it has focus, enter the callsign, click on the twpsk window
again to continue his QSO. If you do it the other way (send QSO information
from the application to the log program) you can keep the log program
running in the background. I think this will make logging easier.

> If we go the other way (app -> log pgm), each app would need a Call box in
> its GUI (repeated code), or some way (highlight the call) to identify
> what to send to the log program.  Wouldn't this cause some confusion 
> because each app may require a different operation on the part of
> the user.  Different GUI toolkits may also require the user to "identify"
> the call differently too (right click, double click, drag, etc).  I saw
> entering the call in the log program as providing a consistent "task" for
> the user.  
> 

Logging may also never be done in a consistent way. Different guis have a
different approach for user interaction. Also, every other programmer may
implement logging in a different way. There is no way you can avoid that.

So I can see your point, but intuitively I would prefer to send information
from the application to the logging program. For a programmer who wants
to implement logging it is as easy as adding a box for the callsign
and a button to click on. 

Also, most soundcard based QSO programs already have some kind of box for 
callsign information, so they can automate part of the QSO.

> Message queues are great.  I've used them a lot.  We could even pass more
> info (call, name, report) and use the message type to retrieve the data.  The
> problem I see here is that the data is sent asynchronously, and the log pigmy 
> would have to constantly poll to see if new data has arrived.   
> 

Well, with GTK this is no problem. Adding a timeout function is part of the
gui toolkit.

> If we use the log -> app approach, and want to pass more data, we would just
> have to agree on a strict, and pass it in the shared memory.  No
> polling is needed.  The app just grabs the data when it is needed, and 
> provides
> a good default value if there is no data.
> 

Yes, this is a major advantage.
If I would decide to use shared memory, I would have to add some poll
function anyway, otherwise the information will never appear in the log.
So I guess when using the app -> log approach it would not make any
difference whether the logging program uses shared memory or message queues.

> So, what do you think?  Am I making any sense?  
> 

I would still prefer to send logging information from the application to
the logging program.
Maybe there are more hams who can say sensible things about this subject.
Xlog now has a project page at the gnu site. There is also a mailing list
for discussion. I am also CC-ing this message to Tomi Manninen, the author
of gmfsk. Maybe Tomi and you could join in at
http://mail.freesoftware.fsf.org/mailman/listinfo/xlog-discussion
Stephane Fillod is now a member of the xlog project. He one of the authors of
hamlib.

> 73,
> Ted - WA0EIR
> 
> BTW - I glad that we're not embedding the log pgm in the apps.  I really
> find that to be less than the best design approach.
> 

Thanks for replying,
Joop PA4TU

> 
> > -----Original Message-----
> > From: Joop Stakenborg [mailto:address@hidden
> > Sent: Wednesday, December 05, 2001 7:52 AM
> > To: address@hidden
> > Subject: logging
> > 
> > 
> > Hi Ted,
> > 
> > I would like to inform you about the status if xlog. I saw  your message
> > on linux-hams about the new twpsk (guess you already saw the  debian 
> > packages)
> > and the integration with twlog.
> > 
> > About the same time you distributed the new version, I was mailing
> > with the author of gmfsk about remote logging. When I saw your message
> > I was kind of surprised that you send information from twlog to twpsk.
> > I was looking for a solution which does the opposite, sending logging
> > information from the application to the logging program.
> > 
> > I would like to go ahead and distribute a new version of xlog 
> > within the next couple of weeks, but it will not support remote logging 
> > as you have implemented it. I hope that's OK with you. Maybe we should 
> > try and see if we can agree on a better integration of twlog, xlog, twpsk 
> > and other software in the near future.
> >
> > Interesting point in your implementation of remote logging is that you
> > are using shared memory. I have been looking at message queues (msgrcv
> > and msgsnd) as a solution. Is there any particular reason why you have
> > decided to use shared memory?
> > 
> > Best regards,
> > 
> > Joop PA4TU
> > 
> > PS. Thanks for the psk31 QSO on 20 meters!
> > 
> >