[Xlog-discussion] Re: hacking xlog-0.4

[Joop Stakenborg]

Stephane Fillod <address@hidden> wrote:
> 
> 
> > > Here are some ideas for internal needs (with better function
> > > names of course! I am rather bad at picking pretty names):
> > > 
> > > log_file_open(pathname, logtype)
> > > log_file_close()
> > > log_get_columns_name_and_width()
> > > log_create_file(pathname, logtype, columns_name[], columns_width[])
> > > and maybe log_add_column(pos, name, width)/log_delete_column()
> > > 
> > > Once the log file is opened, we may need:
> > > 
> > > qso_t* get_qso_from_nr(nr)
> > > update_qso(nr, qso_t)                    
> > > nr add_qso(qso_t)             return newly created unique nr
> > > foreach_qso((*fn)(qso_t))     iterate on each qso, call fn() with qso data
> > > delete_qso(nr)
> > > 
> > 
> > Phew, you seem to be good at thinking ahead. I am used to programming
> > and adding functions as I need them....
> 
> Well, me too, I'm used to programming and I think we
> need to add theses to split into different tasks and work in parallel.
> Anyway, what do you think of these functions?
> 

log_file_close() would have to be log_file_close(logtype).
Logtype can be any of [text,db3,sql].

log_delete_column() -> log_delete_column(pos).

When a qso is deleted, the log is renumbered. This is something to
remember. As you may have seen from the log file itself, the number is
derived from the position in the text file. The top entry in the
file is QSO #1, etc. When refering to a QSO in the clist, the QSO 
number is derived from the first field.

The functions look fine otherwise.

> 
> > > Questions:
> > > * Should we support more than one opened log file at a time?
> > 
> > Eventually, I think we should do that. I was already thinking
> > about renaming the log to something more sensible, so we can
> > have things like hf.xlog, vhf.xlog, 50Mhz.xlog, etc.
> 
> The .xlog is a good move for the extension name. Let's say this will
> be the extension name of the future flexible format. This way we can
> distinguish between old and new format. 

Yes. let's do that.

> The question regarding more than one opened log file is necessary
> to know whether the log_file_open()/log_file_close()/etc. need a
> "handle" parameter.
> 
> > > * what is the authority for the QSO list during run time? Is it the log
> > >   file, or is it the clist of the GUI?
> > > 
> > 
> > It's the clist. The file is only changed when you save it.
> > I don't want the gui to be blocked by disk I/O.
> 
> Allright, let's keep xlog lightweight.  However, that'd be *really* neat
> to use the get_qso_from_nr()/update_qso()/add_qso()/etc. as
> soon as possible, so that if we change our mind in the future, this
> will be a lot easier to do (just by changing implementation of
> get_qso_from_nr()/update_qso()/etc.). 
> And anyway, these function will help us from now on.
> 
> Oh, BTW, what about having xlog save the log file regularly, so you won't lost
> a day full of QSOs beacause of a power outage (at least we're immune to
> the blue screen of the death :)
> 

Jup. I wanted to add a timeout function already for this.
In the preferences dialog you can enter a value for saving every x minutes.
We should put this in the task list.
I will start and write a task list over the weekend and send it to you.
We can then start adding defined tasks to the project task manager.
There is a lot of stuff in my TODO file, mostly from people who
emailed me.

> > Ah, you are in the hamlib project. That's great.
> > I might help you out with the Kenwood support.
> > I've got a TS-870.
> 
> Yupee! Finaly someone to test the kenwood backend. 
> Actually, Franck started the Hamlib project with me, and since he's pretty
> busy, I'm right now the main developer of Hamlib, with beta-testers, 
> webmasters, and people helping around. Robert (DL1NC) also develops
> a rig control GUI, project named 'kontakt' on sourceforge.
> 
> I've only been able to test the kenwood backend with my TH-F7E.
> Please let me know how Hamlib works on your TS-870.
> I can sure help you for a quickstart, and any wish list.
> 

Okay, I'll have a look over the weekend. I have been planning this
for some time. 

> 
> > I am still evaluating the msgbuf. It is in an early stage. Right
> > now, I am talking to the author of gmfsk to get things working.
> > The message will probable have some kind of version string, so I
> > can change the format in a later stage.
> 
> Good idea. Maybe discussing this issue on a mailing list would be easier.
> see below with project registration on savannah.
> 
> > Yes. This poses a problem. How does xlog know where a message field
> > should go? I was thinking of using some schmeme like:
> > 
> > '<program name>~<message version 
> > string>~<date:____>~<time:____>~<call:____>~ etc'
> > 
> > With '~' being the field seperator (we need something unique). For example:
> > 
> > 'gmfsk~1~date:17 Nov 2001~time:1200~call:PA0DIN~name:din~QTH:Nijmegen'
> 
> To my mind, message version should come first, and on a fixed length field,
> allowing only numeric value. Something like [0-9][0-9]~<program name>~etc.
> example:  '01~gmfsk~date:17 Nov 
> 2001~time:1200~call:PA0DIN~name:din~QTH:Nijmegen'

Now that I think of it, this would be more sensible:
'version:01~program:gmfsk~date:17 Nov 
2001~time:1200~call:PA0DIN~name:din~QTH:Nijmegen'

> 
> IMHO, there's a lot of string parsing in this message format.
> This is particulary what makes things slow, esp. without help from lex.
> To be convinced, just have a look at the OLE system under win32...

Bwech! Don't start about win32, makes want to me puke.

> Since we're on the same host (no endianness problems), why not using
> binary fields? I'm not advocating it, just wondering myself.
> In the other hand, the problem with predifined binary values is it kills
> flexibility and downward compatibilty. Maybe this text format should suffice, 
> as long we
> agree on the most used  field names and representation (e.g. 'call' or
> 'callsign', upper/lower case, case sensitive, GMT time or not, date in 
> english or
> localized, etc.)
> 

It is hard to avoid string parsing.
Another way would be to use fixed field lenghts (preferable all the same width)
with pre-defined field variables. Then we would only have to move the pointer
to the next field, which is really fast. What do you think?

> Anyway, having '~' as the separator is a bad choice IMO. Just imagine someone
> putting a '~' in a field value. The application would have to escape it,
> and then escape the escape character, and so on. To be more C oriented, 
> we can replace the '~' separator by the null character '\0'.
> 

Okay, makes sense.

> ':' doesn't suffer from this problem because we implicitly assume field names
> cannot be made of ':'.
> 
> > The msgbuf is checked once a second by using gtk_timeout_add and using
> > IPC_NOWAIT.
> 
> good
> 
> > Okay, put it on the same line. Of course you should support the old
> > format also, so you can migrate to the new format easily. Version
> > 0.5 uses 2 struct variables called state.majorversion and
> > state.minorversion which you can check. So you can check these
> > variables at startup and then convert to the new format.
> 
> Well, the problem is people upgrading xlog and still having old log files.
> Let's say the new format will have '.xlog' extension. Having the pathname
> in the preferences would be nice. People loves to know where their
> critical data files sit, and backup them when they are paranoiac.
> 
> Then, at startup, xlog can check for the presence of the old log file format
> in ~/.xlog/log, and if found, load and delete it. Then, at xlog close time,
> save the clist with the new file format (and pathname from preferences).
> This should be seamsless for the user. 
> Next time, since there's no more ~/.xlog/log file,
> log_file_open() would open the new file.
> 

Okay, looks good.

> > Let's not use cvs. I hate it. I can see why people use it, but
> > unless you have a decent network connection, it is unusable.
> > I think it is great for local project management on a LAN, but not
> > over the internet.
> 
> Yes, cvs s a bit slow over a modem, but still very useful to exchange
> bits of code, and beta-testers can even see and test in between release 
> versions. But I respect your choice.

I have used cvs for over a year with a modem. It is unworkable.

> So how do you think integration can be done?  Can you upload
> some development versions on your web site and then
> I would submit patches to you for inclusion (praying code hasn't changed
> under my feets) ?
> 

Would you mind waiting 1-2 weeks? Version 0.5 is almost done.
Only the message queue stuff has to go in.
If your fingers are really itching, I can of course upload a development 
version.
Just let me know. I don't really mind.

> 
> 
> Cheers,
> Stephane F8CFE

Thanks for setting up the project page.
Distributing patches can be done through the mailing list I think.

I can then upload pre versions to http://people.debian.org/~pa3aba/download

Thanks,
Joop PA4TU

-- 
Joop Stakenborg
FOM-instituut Rijnhuizen
tel. 030-6096862