Discussion:
Status of PostgreSQL port of cddbd
Kevin Dalley
2003-12-15 01:17:26 UTC
Permalink
I have made a lot of progress with the PostgreSQL version of cddbd.
Most of the code is somewhat tested. Is there a cddbd test suite to
verify functionality? I suspect that I have misinterpreted some
items, and just screwed up others. The database has separate columns
for artist and title, allowing for multiple artists for each track.

I have quite a few questions which I will send in separate email.

Now, some general information. The disc space required is similar to
that used by the standard files. The exact numbers depend upon what
features are required, and how many indexes are built. The number of
files has gone down, of course. reiserfs is probably not necessary.

In many cases, I use the same infrastructure and functions as the
current cddbd. history files are still in text, though they probably
should be moved to the database some day. Posts still use plain old
text files. I think this is reasonable. The fuzzy index is stored
the same way, but it is generated for the database.

The PostgreSQL server can do *almost* all of the needed functions,
including updates, transmits, validating entries, etc. I haven't
strongly tested the merging code. I suspect there are a few
outstanding bugs.

I'm still missing cddbd_do_catchup, the "-T option to cddbd. This
option resets the transmission history to a known time. In order for
this option to work, I have to add time stamps for each CD entry. This is
doable, but I had other things to do first.

I'm missing cddbd_match, which looks for files which should be linked.

Most other functionality should be there; not all of the functionality
has been tested. I usually find bugs during testing.

I would like to have some people test the software in the next few
weeks, after I perform some more cleanup. Is anyone interested in
testing the software?
--
Kevin Dalley
***@kelphead.org
Jacob Alifrangis
2003-12-15 08:23:44 UTC
Permalink
In other news, I have begun work on a MS-SQL Version of cddbd.

It is a work in progress, but In several ways, it is much faster than cddbd
for unix.
IT supports regular expression matching and direct lookup. I am still trying
to decide how best to license the server since it uses NO code from
freedb.org, it only has an import function for the existing freedb data.

It supports star or descendant replication methods for a system wide
load-balancing update scheme. Meaning that all updates are processed locally
then uploaded to a master server where they are validated and redistributed
weekly, And automatically.

The software is written in c# and vb.net and will, when ready compile on
mono.

Let me know, since this is really a whole new animal, what you think. This
might wind up being a competing product for the freedb system, it might not
be.

-----Original Message-----
From: fdb-dev-***@freedb.org [mailto:fdb-dev-***@freedb.org] On Behalf
Of Kevin Dalley
Sent: Monday, December 15, 2003 12:16 AM
To: fdb-***@freedb.org
Subject: [fdb-dev] Status of PostgreSQL port of cddbd

I have made a lot of progress with the PostgreSQL version of cddbd.
Most of the code is somewhat tested. Is there a cddbd test suite to
verify functionality? I suspect that I have misinterpreted some
items, and just screwed up others. The database has separate columns
for artist and title, allowing for multiple artists for each track.

I have quite a few questions which I will send in separate email.

Now, some general information. The disc space required is similar to
that used by the standard files. The exact numbers depend upon what
features are required, and how many indexes are built. The number of
files has gone down, of course. reiserfs is probably not necessary.

In many cases, I use the same infrastructure and functions as the
current cddbd. history files are still in text, though they probably
should be moved to the database some day. Posts still use plain old
text files. I think this is reasonable. The fuzzy index is stored
the same way, but it is generated for the database.

The PostgreSQL server can do *almost* all of the needed functions,
including updates, transmits, validating entries, etc. I haven't
strongly tested the merging code. I suspect there are a few
outstanding bugs.

I'm still missing cddbd_do_catchup, the "-T option to cddbd. This
option resets the transmission history to a known time. In order for
this option to work, I have to add time stamps for each CD entry. This is
doable, but I had other things to do first.

I'm missing cddbd_match, which looks for files which should be linked.

Most other functionality should be there; not all of the functionality
has been tested. I usually find bugs during testing.

I would like to have some people test the software in the next few
weeks, after I perform some more cleanup. Is anyone interested in
testing the software?
--
Kevin Dalley
***@kelphead.org
Kevin Dalley
2003-12-15 21:37:25 UTC
Permalink
My code will definitely be open source. Since it is derived from the
current cddbd, I don't have a choice. It's what I prefer, regardless
of the license. I'm using other people's knowledge; I prefer to share
my own. Making it open source, will encourage its spreading.

I hope that my code is a new protocol for cddbd, if it it passes the
tests. I have had some words of encouragement of joerg, but no
promises, definitely without seeing my work.

By the way, my new code is largely in C++, with some of the original
cddbd code remaining in C, other code changing to C++.

In theory, PostgreSQL could be changed to another SQL, but I haven't
worked to ensure that.
Post by Jacob Alifrangis
In other news, I have begun work on a MS-SQL Version of cddbd.
It is a work in progress, but In several ways, it is much faster than cddbd
for unix.
IT supports regular expression matching and direct lookup. I am still trying
to decide how best to license the server since it uses NO code from
freedb.org, it only has an import function for the existing freedb data.
It supports star or descendant replication methods for a system wide
load-balancing update scheme. Meaning that all updates are processed locally
then uploaded to a master server where they are validated and redistributed
weekly, And automatically.
The software is written in c# and vb.net and will, when ready compile on
mono.
Let me know, since this is really a whole new animal, what you think. This
might wind up being a competing product for the freedb system, it might not
be.
--
Kevin Dalley
***@kelphead.org
Tom Malcolmson
2003-12-15 21:50:11 UTC
Permalink
Thanks for making it OSS.

Is it cross-platform (win32 & linux)?
Does it use the STL, boost, wxWindows?

Tom.


----- Original Message -----
From: "Kevin Dalley" <***@kelphead.org>
To: <fdb-***@freedb.org>
Sent: Monday, December 15, 2003 4:37 PM
Subject: Re: [fdb-dev] Status of PostgreSQL port of cddbd
Post by Kevin Dalley
My code will definitely be open source. Since it is derived from the
current cddbd, I don't have a choice. It's what I prefer, regardless
of the license. I'm using other people's knowledge; I prefer to share
my own. Making it open source, will encourage its spreading.
I hope that my code is a new protocol for cddbd, if it it passes the
tests. I have had some words of encouragement of joerg, but no
promises, definitely without seeing my work.
By the way, my new code is largely in C++, with some of the original
cddbd code remaining in C, other code changing to C++.
In theory, PostgreSQL could be changed to another SQL, but I haven't
worked to ensure that.
Post by Jacob Alifrangis
In other news, I have begun work on a MS-SQL Version of cddbd.
It is a work in progress, but In several ways, it is much faster than cddbd
for unix.
IT supports regular expression matching and direct lookup. I am still trying
to decide how best to license the server since it uses NO code from
freedb.org, it only has an import function for the existing freedb data.
It supports star or descendant replication methods for a system wide
load-balancing update scheme. Meaning that all updates are processed locally
then uploaded to a master server where they are validated and redistributed
weekly, And automatically.
The software is written in c# and vb.net and will, when ready compile on
mono.
Let me know, since this is really a whole new animal, what you think. This
might wind up being a competing product for the freedb system, it might not
be.
--
Kevin Dalley
_______________________________________________
fdb-dev mailing list
http://dtype.org/mailman/listinfo/fdb-dev
Kevin Dalley
2003-12-15 22:36:08 UTC
Permalink
Does multiple *nix count as cross-platform?

So far, I have only compiled it on Linux. It should not be strongly
dependent on which Unix architecture you use, but this is untested. I
would like to add autoconf, automake, and friends. This should help
the Unix ports, and perhaps Windows as well.

This code is only an update for the server cddbd, and thus doesn't
have a graphical interface. It requires new clients to fully take
advantage of some of its changes, but it should work well with current
clients.

It uses STL, but not boost or wxWindows. Some of boost may be a good
idea. In many cases, I continue to use the C constructs originally
used in cddbd, though the code would be written differently if it were
in C++ from the beginning. There are a few places which could use
SQL, but don't for partly historical reasons. The data itself is in
SQL, of course. Some of this will change over time, if the release is
successful.

Some code needs to be refactored. I'm not happy with the C++
PostgreSQL library, and haven't used it, though I have heard that it
has recently improved. There are many improvements to be made. I
could make an unpaid career out of this for the future.
Post by Tom Malcolmson
Thanks for making it OSS.
Is it cross-platform (win32 & linux)?
Does it use the STL, boost, wxWindows?
--
Kevin Dalley
***@kelphead.org
Loading...