> Suggested naming scheme
>
> 1. Standard C library as described at http://www.dinkum.com/htm_cl/
Fine. This is Plaugher's company and his C standard docs are excellent.
> 2. CDIndex_nocaps = type or enum
> 3. CDIndex_InterCaps = function name
A matter of taste.
My eyes are used to either '_' as separator between words in lower case (c_style)
or capitalization (JavaStyle). Using both looks strange.
> CDIndex_Net_CONNECTION CDIndex_Net_CreateConnection(char *where);
> void CDIndex_Net_DisposeConnection(CDIndex_NetConnection *);
> char *CDIndex_Net_GetErrorState(CDIndex_NetConnection *);
This uses types that represent certain entities, like the connection (good) but
on the other hand do use fundamental types (not prefix_url or prefix_rc) for the
destination and return values.
> int CDIndex_Net_SendData(CDIndex_NetConnetion , uint8 *data, int data_length);
> int CDIndex_Net_ReadData(CDIndex_NetConnection, uint8 *buffer, int buff er_length);
Aside from the naming (I prefer open/read/write/close) which is a matter of taste,
I want to avoid having the user doing transfers of bytes.
A user should rather transport higher level units of information, like prefix_toc,
prefix_artist, prefix_title, ... logical chunks not bytes.
> struct CDIndex_track {
> char *name;
> char *artist;
> };
>
> struct CDIndex_description {
> int track_count;
>
> char *title;
> char *author;
>
> CDIndex_Track *track_list;
> };
(artist, name) or rather (act, description).
Sony has plans already to fiddle extra stuff like URLs into the description.
(see Sony CD Text site)
Speaking of the same site that shows enabled players with Japanese displays,
of course they will use Kanji and Kana characters for Japanese CDs,
representing it in some wide character string .. in other words we should
have a look at internationalized software at some point to decide
string representation.
> void CDIndex_DisposeDescription(CDIndex_description *);
>
> // Gets a description for the given toc.
> // If toc==null, use current CD.
> CDIndex_description *CDIndex_GetDescription(CDIndex_toc *toc);
This is quite hackish. In fact I find myself looking at your implementation
to find out about your design ideas to then comment the implementation.
> Note: All the work of getting actual XML is done
> platform-independently. All the work of parsing the XML into a
> description is too.
Of course.
> Issue: The cdindex server currently bounces you around with a bunch of
> HTTP redirects when you approach it with the URL given out by the
> client app. There needs to be a guaranteed shortcut through all this
> nonsense. I'd recommend making a non-HTTP protocol to pipe requests to
> the web server (for query and submission). This should really not be
> hard, at most a half hour's time with perl.
I suspect you are directly talking with the server (via 'telnet <URL> http'
or like) and experience some redirects that might be due to several hosted
sites on the server machine.
Now the general items.
Before I craft a library I need to have some thoughts about what I
want to achieve, who uses the stuff and how I think the programs will
look like that use the library (what kind of app, what kind of platform).
I have my ideas, you might have yours (and I don't dare to ask what
tricks Robin has in his sleeves :-) so lets synchronize them first,
before we start hacking.
1. Big goals
a) We do this because we think that cddb has become obnoxious
b) We want a system of free data and open standards
c) We want to have a solution that is useful and cool
d) We want to have fun building such a system
a) nuff said
b)
b1 => we have to state a license for the data and put this
in a kind of CD Index magna charta on our web site
(at present it is kind of coded in the main page)
b2 => we have to state the communication protocols,
data encoding and put them on the web page
(at present part done), we provide reference
implementations, and have to state the licenses
for this stuff too
c) => what use? I see these:
c1 - cd player apps or more genereal media player apps
c2 - providing rippers with information from the
database for enriching data (e.g. for mp3 creation)
c3 - harvesting information from rippers (e.g. that
decode CD Text or other Enhanced CD data) or
other CD analyzing tools
c4 - allowing people to do queries of various kinds
on the collectivly collected data
(what albums/tracks are available by an act?,
who did perform 'starship edelweiss'?,
what is the Internet Rap top ten?
submission stats and so)
c5 - allowing people to build local databases
(e.g. the cd's they own, or about cd's
they are interested in)
and sync them to various degrees with the
collective data
c6 => this means must make it easy to realize this
stuff by creating protoype apps, libs and glue.
c7 => this means a wide audience, including the
windows world and not only geekish systems
c8 => a wide audience of users and
of programm writers
d) => those who enjoy it stick here i guess
2. first iteration
We have a prototype system now that is able to store and
retrieve such data over the Internet.
We have a server, we have some clients on some of the major
platforms.
3. second iteration
We have to improve the usage (c1 - c8)
server
- improve data model (
- improve editing features (to allow more accurate data)
- improve queries
- add bulk import/export mode for node synchronization
- client redirection
client
- add popular players
- improve free rippers
Short sleep break now - I will post a followup in a couple of hours,
where I will have a deeper look at c1-c8 and derive some library
design musts from them (portability, packaging, our weaknesses
and strengths..)
Regards,
Marc