Martin Nilsson wrote:
>
> Hello everyone, assuming that there are people on this list. I haven't
> heard anything, but I haven't subscribed until a few hours ago. I have a
Unfortunately, the cdin nospam at cdin.org mailing list is the only one with a web
archive, and the cdin.org domain didn't come up until just very
recently. I'm starting to copy posts and replies into the archive,
though, for future readers.
> few thoughts about the client and the database that I would like to
> mention to you and hear what you think about them.
>
> The Client.
>
> - Even if one should continue to use a web interface, which I don't
> think is a good idea, the client should have a GUI.
I think most clients already do this and will continue to do so. This is
why it is important to define a protocol for communication with the
server. The clients are then free to do as they please.
> - It should be fairly simple to look for data in Microsoft's CD-player
> "database". Looking in the off line CDDB database might however
> contaminate the code.
Yup. Michael Oliphant wants to work on a common library. It would
probably have these characteristics. Michael appears to have a very good
head on -- keep it as simple as it can be, and no more complex.
> - It should notice the user that there is already a disc present with
> the same ID, if that is the case, when he tries to do an entry
> submission.
The UI would probably start out differently if an entry already existed.
> - Clarify what "Artist" means. If London symphony orchestra plays a leid
> by Edvard Grieg, who is the artist?
Tough call. No ideas here...
>
> The Database.
>
> - All entries should be stored as Unicode. Or to be more correct, the
> database should input and output unicode data, how it is stored is of no
> concern to me. If we are to get an IETF approval of any protocols they
> have to support unicode according to their new guidelines.
Ah. Actually, my current database design
(http://www.cdin.org/impl/tables.html) has the columns as "VARCHAR". I
need to look at the MySQL doc to see if that is 8-bit compatible. It
probably is (and BINARY just means that \0 can be stored).
Anyways... I think the database can store it in Unicode or UTF-8 as the
server sees fit. The protocol "should" be HTTP and XML, which is
Unicode-capable (and typically encoded as UTF-8).
The IETF standards process is long and complex. If you'd like to
shepherd a protocol spec thru there... go for it :-) Personally, I
think it is reasonable to just post it to a web page and leave it at
that.
> - I think that songs should be kept in one database and albums in
> another. The albums database would then only have references to the
> songs. All CD:s containing one song (singles, albums, compilations,
> albums with different TOC) will then be affected by a update in the
> songdatabase. One could possibly use the ISRC as part of the
> identification of a song. I've been told that the ISRC is encoded on the
> Q-channel on many CD:s.
Please refer to the table scheme that I reference above. We've separated
out the tracks for a CD, but haven't gone as far as to separate out the
songs. Is that really necessary? I can't see a lot of duplication
between songs on different CDs. The effort probably is not worth it (I
mean how many songs by a particular artist and recording appear on
*different* CDs (and I don't mean with different hash values)).
Cheers,
-g
-- Greg Stein, http://www.lyra.org/