Re: [Xlog-discussion] xlog-0.9 released

[Eric S. Johansson]

Joop Stakenborg wrote:

> I don't really know if Berkeley DB format would be an improvement. We 
> would probably look at more calculation time. The benefit of the current 
> log format is that you can load it into any text editor, which I have 
> done a lot in the past to merge, split and sort logs.

this is undeniably good thing.

> A SQL backend would be nice!

IEEEE NO!  I have spent the past 20 years watching virtually every 
single project I've been involved with using a database fail miserably. 
 they have fail and because they take longer to develop, less reliable 
in day-to-day operation, and need greater hands-on maintenance.

I am currently trying to set up horde+imp+turba+kronolith for a 
customer.  Besides the fact that the suite is "deficient" in 
documentation, its dependencies on databases have cost me God knows how 
much time.  You need to become a full-fledged DBA to install and run a 
calendar application. GFD, I swear it isn't a program suite as much as 
the jobs program for administrators.

> We would only need xlog for displaying the 
> data and let the database do the work. I have set up a SQL database a 
> couple of times, it is not for the beginner. So a starting linux user 
> could use the simple ascii format, the more experienced user could 
> connect to a database.

if you really want a database to work with that's not horrible but still 
can scale, take a look at sleepy cat.  Otherwise there really isn't any 
advantage to going with DBM type systems unless they allow you to do the 
same kind of specialize searching that a fuller feature database does.

In any case, tell me what kind of data relationships you are interested 
in and I will see if I can think of some alternative structure that 
won't be too ugly.


> The major benefit of using SQL is the possibility of using big logs with 
> 10.000+ records. On the other hand, we would still need the slow gtk+ 
> list widget for displaying the data. So we need to re-think about how to 
> display the data when using SQL. Maybe we need to design our own widget 
> for this or wait until the next gtk+ version, which will probably have 
> better support for displaying large amounts of data in a list.

if you're having a problem with large list widgets, you'll need to 
rethink your design no matter what.  A technique I've used relatively 
successfully is the sliding window approach.  Generate a list of keys, 
position yourself to the right spot on the list and then start fetching 
records for the visible keys plus a couple screens on both sides of the 
scrolling box.  the only time you need to update that list is when the 
date of the file changes relative to the date of the list creation. 
When you approach within one-half screen of an end on either side, start 
fetching records for the next screen+.

is really depends on how fast one can fetch records and how much 
background retrieval will cost in terms of screen updates.  Sometimes 
you need to increase the size of the window as well, change trigger 
points and rate of retrieval of records.

if you really want to get fancy, you can look at velocity of movement 
and use that to choose the size of the array fetched.  I recommend 
starting simple if you should choose to move to this technique and get 
the basics down etc.

by the way, I'm really looking forward to trying out xlog+gmfsk this 
weekend.  or at least, getting back to debugging my icom interface plus 
digi-mode board I homebrewed.

---eric

--
Speech recognition in use.  Incorrect endings, words, and case is
closer than it appears