Re: [Xlog-discussion] xlog-0.9 released

[Nate Bargmann]

* address@hidden <address@hidden> [2003 Nov 14 13:38 -0600]:

> Well, since I brought this up, let me try asking this another way; Why embed 
> a 
> db if you don't need to to get the same information ? I worry about adding 
> any db when it isn't needed as it takes away from the simplicity I find 
> valuable in GOOD software that is well written.

I guess it depends on where the simplicity lies.  I've been able to do a
slight bit of tinkering with SQLite over the past few days and I have
the impression that using the SQLite library offers some sophisticated
record keeping while allowing the Xlog code to be simply written.

This is, of course, a trade-off.  Extensive searches and colation of
data can be done by Xlog with several staticly stored search pattern
SQL strings that are then passed to the library.  Xlog would need to 
concern itself with displaying the results rather than having to 
contrive the search algorithm and displaying the results of a flat text
file.

Of course, the simplicity of the stored log is lost as it is no longer a
flat text file, so simplicity for the user in one respect may be lost.
On the other hand, SQLite does seem to offer some means to avoid DB
corruption.  Flat text files can be corrupted by bugs.  As always,
important data should be backed up!

> Or put another way, can you give me an example of how this rdbms is to be 
> used, and to what end (purpose), that I cannot also do without using a 
> rdbms ? i.e. What is missing from what we already have ?

Off the top of my head here is but one example.

Due to moves in life I now have QSO data that span two calls, four
permanent QTHs, and numerous mobile contacts that I've noted at least my
transmitting county in case of QSL requests.  This is relational data
(at least that's how I understand it, I could be wrong) as there is at
least one and probably more QSOs per transmitting location.  An RDBMS
seems to me to be a powerful way to tie all of this together so that I
can do searches of my log data in a number of ways.  As I am a neophyte 
to the ways of RDBMS, I assume that building such things as indices 
between tables allows this magic to happen.

As it is now I have to be sure to enter my transmitting location in Xlog
in a consistent manner so that searching the log would reveal something
useful.  An alternative is a seperate log file for each location, but
that leads to its own complexity.

> On a lighter note, I am going to be out of town at the Ft. Wayne (Indiana) 
> Hamfest starting later today. I won't be able to resume reading my mail for a 
> few days unless I don't decide to sleep. So have fun discussing this.

Not much has been said!  I'm tossing out my ideas for consideration.
They are not demands by any means.  I want to learn the pros and cons of
my ideas and if they help Joop in any way, great!  Ultimately, what
direction Xlog takes is up to Joop and I appreciate the hard work he and
others have put into the program thus far.

73, de Nate >>

-- 
 Wireless | Amateur Radio Station N0NB          |  Successfully Microsoft
 Internet | address@hidden               | free since January 1998.
 Location | Bremen, Kansas USA EM19ov           |  "Debian, the choice of
  Amateur radio exams; ham radio; Linux info @  |     a GNU generation!"
             http://www.qsl.net/n0nb/           |   http://www.debian.org