data-design question

[Charles Hartman]

On Sep 24, 2005, at 9:23 PM, Alex Tweedly wrote:

> Charles Hartman wrote:
>
>
>> Ah, you're right. I remembered the Oracle limitation, but over-  
>> generalized.
>>
>> But $149 for the plugin is not what I would call "inexpensive." I   
>> suppose if you start from a RunRev assumption, and have   
>> (remunerative) applications for it, then it is; if you start from  
>> a  Dreamcard assumption, no.
>>
>>
> Yeah, I agree the plug-in is kind of expensive for personal hobby  
> use. If it were me, I'd take a different approach.
>
> Rev front end, talking over a TCP socket to a Python back end.
> Python (plus pysqlite2) for the back end.

Python I know. SQLite I don't, but I should learn. Do you know of an  
OSX pysqlite binary distributable, aside from Darwinports (which has  
been messy when I've tried to use it in the past)?

Sockets I've never dealt with. Time to learn that too, I guess.

>
> Not sure, but I'd probably make the socket protocol take SQL  
> statements and return lists of results (as well as any other  
> command + responses I felt would be useful).
>
> freedb.org has some data that would be a basic start for data entry  
> - doesn't have anything like the complete data you want, but it  
> would be a start if you could get track names from there - you'd  
> still need to add the author and individual player info.
>
> If you're interested in collaborating (and assuming it's going to  
> be Open Source when you're done) I'd be interested in helping,  
> particularly  with the Python / sockets parts ..... I'd probably  
> want to make it capable of storing multiple tunes per CD track and  
> some other things that I think would be extensions beyond what  
> you'd need.

I'm sorely tempted. But I'd have to do this stealing time from  
teaching and closer-to-home research, and I'd be afraid I wouldn't be  
a very reliable collaborator. Maybe we could at least trade some  
ideas off-list about how it ought to work?