<tvon> :-) <tvon> anyways..... <tvon> you have any thoughts on the SMDP? <bkeil> ugh... <tvon> heh <bkeil> You want me to think? <tvon> you dont _have_ to <bkeil> I'll try. <bkeil> Lessee <bkeil> ... <tvon> btw, I am trying to enlist someone new <tvon> who has 18 years exp doing db design <bkeil> offering them a signing bonus? <tvon> yeah, told em I would give them "mad props" <tvon> I put up a "project help needed" thing at SourceForge...and he replied <bkeil> Alright! That'll bring'em in for sure. <tvon> theyll be breaking down the doors in no time <bkeil> I can see someone out on the street... "Will work for `mad props'" <tvon> I did mention this project on a local LUG, and a guy replied saying he would love to work for my company <bkeil> So my first thought about SMDP is: <bkeil> I'm still not convinced that we need an album song table. <bkeil> My second though is: I'd like to wee a "guest artist" table. <bkeil> Or, see it, too. <tvon> how do you want to handle albums? <tvon> just list it in the song table? <bkeil> I think so... <tvon> add an album field I mean <tvon> hmm.... <tvon> I suppose you could figure out the album genre (which isnt _that_ importnt anyways) by averaging out the song genres <bkeil> It seems to me that most people want their filesystem to also.... <bkeil> ...include some sense of the structure of the collection <tvon> how do you mean? <bkeil> For example: <bkeil> My mp3s are all in /opt/mp3 <bkeil> under the directory of album artist/album <bkeil> and then the filename is <tvon> yeah <bkeil> album artist - album - track title (song artist).mp3 <bkeil> So... really, unless I set up symlinks <bkeil> ... <bkeil> ...The same song on two albums is going to appear on my hard drive twice or more. <tvon> yeah.... <bkeil> Which doesn't seem like a horrible problem because I've got nine GBs dedicated to /opt/mp3, and I can easily add more. <tvon> oh...yeah <tvon> Im not really worried about dupes...... <tvon> not anymore anyways <tvon> Im not sure how you relate dupes to the album table (?) <bkeil> So my real feeling is that everything we need to know about albums can be geamed from the song table, with the exceptions of: <tvon> ah <bkeil> 1. Album artist (different sometimes for song artist) <bkeil> 2. Album release date (irrellevant for songs) <tvon> ah crap....do you have a IRC logger? (btw) <bkeil> Nope... sorry... Lemme check if debian has one "ready to go" <bkeil> ...no... doesn't seem to be one packaged... <tvon> dont think so....I apt-cache searched for irc | grep log and didnt find anything <bkeil> Hold on... I just found eggdrop. <tvon> Felix has one but he is MIA <bkeil> It might be able to log... <tvon> and I am rarely on IRC <tvon> ah..think I have it <tvon> excellent....I got it <tvon> logging like a pro <bkeil> Are you going to set it up, or should I work on setting it up? <tvon> I got it <bkeil> Oh....! <bkeil> I need to go AFK for a sec... <tvon> "/set log on" worked (random shot in the dark) <tvon> aight <tvon> ...now to figure out how to convert this stuff to html.... <bkeil> Your client is logging? <tvon> ah crap...it logs _everything_....my help commands too.... <tvon> oh well... <tvon> yeah, tis logging....will figure out a way to convert it to html later <bkeil> OK... to review: <bkeil> So my real feeling is that everything we need to know about albums can be geamed from the song table, with the exceptions of: <bkeil> 1. Album artist (different sometimes for song artist) <bkeil> 2. Album release date (irrellevant for songs) <tvon> ok...... <bkeil> 3. Album-specific genres (like Soundtrack) <tvon> a few thigns: <bkeil> 4. The overall prefence of tha Album. <tvon> yah... <tvon> cover image <bkeil> OK... cool. <bkeil> 5. Cover image :) <tvon> dont you think thats enough stuff to warrent a album table? <bkeil> Oh yes.... <tvon> ah, ok <tvon> :-) <bkeil> I'm in favor of an album table. <tvon> oh, ok <bkeil> I'm against an album-song relation table. <tvon> oh....hmm... <bkeil> With the exception that that table _is_ the song table. <tvon> so....what woudl the album-song table be? <tvon> song_id/album_id ? <bkeil> Yeah... whatever's been being discussed on the mailing list... <bkeil> That's what I though Xavier was suggesting. <tvon> oh....mmm...hold on...lemme pop up his mail <tvon> OH...ok....my head was elsewhere... <tvon> (tis tough to keep track of all this stuff :-)) <bkeil> That;s certainly unfortunate. <bkeil> ...about your head, that is. <tvon> heh <tvon> that relates to track numbers....... <tvon> which was the entire prupose of the table I think....which seems like overkill.. <bkeil> Should that database contain the (cover) image itself, or a URI pointing to the image? <tvon> not sure about that one... <bkeil> me neither.... I don't have a strong opinion. <tvon> if it was just the URI, it could link to a seperate server.... <tvon> (in some random fantasy situation) <bkeil> It could get the images off of CDNOW.COM, for example. <tvon> Id say the URI <tvon> yeah.. <bkeil> Cool <tvon> as for the song-artist table...I see why you dont want it.... <tvon> I think its entire purpose was the tracknum...... <bkeil> I had a lot of trouble understanding exactly what the situation was. <tvon> I often do... <bkeil> Maybe I should learn French, so that he could explain it to me a little better. <tvon> on a related subject...I am working on a thorough "project status" page to keep things in order <tvon> yeah, slight language barrier there <bkeil> When I learned German, everything I knew about Frenchh got pushed out of my head. <tvon> gads...I took german a while back.....and spanish a few years after... <bkeil> Now I'm studying Swahili, I hope the same doesn't happen. <tvon> I would starve to death if I was dropped intot he middle of germany or spain though <bkeil> Germans mostly speak pretty decent English, though... They have to study a minimum 5 years of it. <tvon> no kidding? <tvon> go germany <bkeil> No.... I think if you go to a Hauptschule you get away with just four years of English. <tvon> do you remember why the tracknum was such an issue? <bkeil> Five years in a Realschule, and six or more in a Gymnasium. <tvon> if you want to get all the tracks on an album...you can query the song table........sort by albumid and all..... <bkeil> No.... I don't remember. <tvon> if you wnat to know which albums a song is on.....do the same....oh....wait <bkeil> As long as we keep a track_num field in the song table, I think we should be covered. <tvon> how would you figure out which albums a song is on? would have to compare the actual names..... <bkeil> Yeah... I wrote about that... <bkeil> I had a few ideas: <tvon> shoot <bkeil> 1. Compare just by names : bad.... Too many songs named "Drive," for example. <tvon> yeah <bkeil> 2. Compare by name and artist, or <bkeil> 3. Compare by name, artist, and playlength <tvon> now, what if you have 5,000....or 10,000+ songs... <tvon> wouldnt that be slow? <bkeil> With 2, you should get all the songs by an artist with the same name, which might be differnt cuts... <bkeil> ...with three, you should only get the same cut of the song, but you might miss on or two because the times <bkeil> are slightly different. <bkeil> It shouldn't be too slow. <tvon> yeah, times may vary when ripping from different cd's...even if same song <bkeil> I didn't write mysql, but I imagine that it would first filter out all the songs that match one critereon <tvon> see...I am no DB expert, as you know......so I just worry about making things fast..... <tvon> if it wont be slow then screw it, we dont need the song-album table at all <bkeil> like the srtist_id first, then check the song titles / <bkeil> whatever. <tvon> ah, yeah, that would speed things up <bkeil> It's the kind of thing that a DB is supposed to be good at. <tvon> alright, than as far as Im concerned the table goes <tvon> now....what else was there? <bkeil> Um.... I dunno.... I think I'm idead out. <tvon> you mentioned two things right? <tvon> heh, ok <bkeil> Ok.... <tvon> oh, did you get a chance to read over my genre thing? on the list <bkeil> Oh yeah.... the "guest artist" table. <tvon> ah, yes <bkeil> That was the other thing/ <bkeil> So, I propose that we have a table with: <bkeil> song_id artist_id <bkeil> And in this table would be all the artist involved in the song, who were NOT credited with either the <bkeil> album or the song. <bkeil> Let me think about this some more. <tvon> sounds pretty good <tvon> what if no artist is the _main_ artist....though no examples come up.... <bkeil> For example, the Supernatural album, by Santana. Carlos Santana is the album artist. <tvon> yeah.. <bkeil> Then, are the other people "guest artists", or "song artists"? <bkeil> I guess I'd like them to be guest artists. <bkeil> I'm conflicted, though. <tvon> yeah, I agree....with the confliction.... <tvon> guest artist would be better in alot of ways....but I dont want to leave a scenario out <bkeil> But it seems that making the guest artists is perhaps cleanest. <tvon> yeah <tvon> I just dont want to leave a situation where people will have to come up with thier own conventions.... <bkeil> But ultimately, that should be the end user's decision. How easy to we want it to be for them to choose the opposite from us? <tvon> like the problem with id3v1 <tvon> heh <tvon>* bkeil shrugs. <tvon> nod nod <tvon> will make it guest artist for now.....see what others think..... <fkr> hi <tvon> Felix! <tvon> hows it going? *** Mode change "+oo tvon bkeil" on channel #smdp by fkr*** Mode change "+oo tvon bkeil" on channel #smdp by fkr <fkr> good... <bkeil> Wee! <fkr> am I late? <fkr> ahoi ben! <tvon> did I get the GMT time wrong? <tvon> I think your late.... <tvon> :-) <bkeil> I don't think so.... I think EST is 5 hours behind GMT. <fkr> it's now eight o'clock gmt isn't it? <bkeil> Does GMT include daylight savings time? <tvon> 8pm GMT....2pm EST.... <tvon> thinkits 9 <fkr> crap <fkr> I'm sorry :( <tvon> oh..dunno <tvon>* fkr owes you guys a beer <fkr> <tvon> heh <tvon> you can ship me a Guinness <bkeil> What time is it in Germany....? <fkr> I've a log-file on the channel...so I'll read later what happened. <fkr> it's 9 here <tvon> ah, cool... <bkeil> Should be okay, then.... I just came early. <tvon> can you convert the log to html as well? Im logging but it also logged all my help commands <fkr> yup, I can <fkr>Pub: #smdp @bkeil @tvon @fkr *** #smdp : End of /NAMES list.*** #smdp : End of /NAMES list. <tvon> cool... <fkr> did anyone else showed up yet? <tvon> nah <bkeil> Nope, not yet. <bkeil> AFK BRB. <tvon> nod <fkr> oki <fkr> tvon, I want to introduce a module 'patches' to the cvs-tree <tvon> we decided that the artist-album table Xav was talking about should prob go.... <fkr> it would hold all patches we do for other applications <tvon> ah, good idea <bkeil> rehi <fkr> you're fast :) <fkr> Playing MPEG stream from Crematory - Temple Of Love.mp3 ... <fkr> :)) <bkeil> I had to pop a frozen burrito in the microwave, <fkr> mmmh.../me is hungry <tvon> mmmmm....frozen burrito... <tvon> lol <fkr> so the table goes? <bkeil> I live on the things. <fkr> I mean the "we-need-to-find-good-name"-table <fkr> ? <bkeil> Oohh.... It was the album song track_num table. <tvon> yeah...I think so <tvon> yeah ben <fkr> yeah <fkr> it goes out? <tvon> we can get the information from the song table...so it is not needed <fkr> so, there is a track_num field in song then? <bkeil> Yeah... I think there should be. <fkr> ok. makes one less table. <tvon> and....we were just talking about guest artists.... <tvon> ho, felix, Im sorry for calling you a twerp <fkr> twerp? <tvon> youll see <tvon> :- <tvon> ) <fkr> no...not on musicbrainz? <bkeil> 3:-= Moo! <tvon> in the log.... :-).... <tvon> anyways.... <bkeil> There's no track_num in musicbrainz... is that what you were saying? <fkr> sorry, we should stay on topic <fkr> ben, no forget it :) <tvon> I reverted us to chaos there for a second.......what about the guest artist table? <fkr> correctz <fkr>* bkeil is confused, but will let it go, anyway. <tvon> guest artist table:: <tvon> album_id aritst_id <tvon> holds: <tvon> only artists who are _not_ listed as main artist for the alum _and_ _not_ listed as main artist for the song <tvon> problem: <tvon> what if neither artist is the main artist? (equal guests) <bkeil> Like duets and such? <tvon> not sure about this one... <fkr> ben, ack. <tvon> yeah.. <fkr> example: <tvon> like bing crosby and.....someone else <tvon> doing christmas carols <fkr> both are main-artists then <tvon> (afk, getting coke) <bkeil> Perhaps we should have a Crosby, Steels, Nash, and Young field: four bit integer: <bkeil> If any of those four artists are involved, we set their bit. :) <fkr> ben...don't get that one, what do you mean? <fkr> hehe <fkr> *giggle* <tvon> both cant be main artist because song talbe only allows one aritst id per song <fkr> tvon, true. <tvon> and I think listing a song twice is overkill.... <bkeil> Maybe "additional artist" and not "guest artist" <fkr> +1 <tvon> true.... <fkr> that would do. <tvon> and just pick a random one for the main listing? <fkr> and if it's a duett, the more famous one is main artist :) <tvon> not quite as clean as I would like....but it works <tvon> yes, def sort by fame <bkeil> There would be context maybe.... <tvon> :-) <tvon> could supply a rating field? maybe.. <tvon> 1 = also main...2= support 3= in the band 4= slept with the signer <bkeil> In a collection of Frank Sinatra's duets, he'd be the main artist, but if he appeared on a U2 album, he'd be "additional."? <fkr> *lol* <bkeil> That's a possibility. <tvon> def need to keep track of the artists sexual habits <bkeil> Does mysql support enums? That be nicer. <fkr> ben, ack. <tvon> yeah on the last one ben <tvon> hold up.. <fkr> we won't support mysql < 3.23.x anyways <tvon> what does ack mean? <fkr> acknowledged. <bkeil> You keep acking at me, Felix? <tvon> I always took it as a bill the cat thing... <tvon> OH...ok <tvon> :-) <tvon> clears a few things up in the back of my head <fkr> it comes from a tcp-session <fkr> ACK <fkr> FIN <fkr> etc. <tvon> OH... <tvon> ok <tvon> excellnet <bkeil> Bill the cat! Yeah! <fkr> anyhow, it means: I agree <bkeil> I see... <fkr> it does support enum. <fkr> so does postgresql <bkeil> That's seems like a good choice then. <tvon> http://www.etria.org/bloom/ <tvon> my bloom county collection <fkr> http://www.mysql.com/doc/E/N/ENUM.html <tvon> enum works <tvon> does perl/php/java support enum? <bkeil> We could make it very specific, like: <tvon> or something comparable? <fkr> tvon, if not there is always work-arounds for such things. <bkeil> Saxophone, Guitar, Backing vocals, etc... <tvon> fkr, ok <bkeil> Java has static constants... <tvon> cuz I plan on using eunms alot inthe API <tvon> for functions to do a bunch of diff related stuff... <fkr> tvon, as long as the api looks the same to the app-developer it doesn't matter how it's solved internally <tvon> cool <bkeil> Yeah abstraction! <tvon> just wanted to make sure it could look the same <fkr> exactly. <fkr> tvon, pretty much that's possible <fkr> tvon except for conventions on names for functions/methods etc. <tvon> like: smdp_insert(SONG, "song_name") or smdp_insert(ARTIST, "artist_name")....etc <fkr> they differ a lot between the languages. <tvon> yeah.... <fkr> tvon, exactly. <tvon> itll work out <bkeil> OT: That might have been the downfall of the Dreamcast.... They didn't abstract the network layer. Game writers had to support dialup and ethernet connections separately. <fkr> let's keep on track with the additional artist thing <tvon> ew <fkr> ben, hehe <tvon> silly Sega <tvon> oh yeah... <tvon> so, enum type maybe? waddaya think? <bkeil> Nothing release in America will support the broadband adapter. :( <bkeil> I'm for it... <tvon> k, how extensive shoudl ti be? <tvon> s/shoudl/should s/ti/it <tvon> fo course <tvon> @#$LKJ@#L: <tvon> sorry <bkeil> ROTFL <tvon> (just happy I can bring joy to others) <tvon>* bkeil catches his breath. <fkr> tvon, the most obvious "artist-connections" we can think of? <tvon> <tvon> Id say so <bkeil> Guitar, Saxophone is probbly overkill.... If we have a comment field, though, it could go there. <tvon> dunno...may be nice to know exactly what the person did <bkeil> song_id artist_id type comment <bkeil>* fkr can't say much on this, since he hardly has CD's with "guest-artists" and such <tvon> just come up with a bunch of insturments....and add a "other" type <fkr> ben, looks good. <tvon> ah yes... <bkeil> tvon, we could also do it that way... <tvon> so, the comment would make it something like main, guest, insturment <fkr> tom, ? <tvon> eh? <tvon> that was the end of my sentance <bkeil> I was think the type could be main, guest, slept_with_singer, and the comment could be "saxophone." <tvon> ah, of course <fkr> ok, got it :) <tvon> then we could link the dirty_sex_id to the other artists so everyone could know how Paula Abdul became so popular <bkeil> Ouch. <tvon> "OH, she slept with keith richards...ok, NOW I understand" <tvon> :-) <fkr> hehe <bkeil> Keith Richards is a modern day miracle. How is he still alive? <fkr> I'll add this table to the core-set then. <tvon> he died 20 years ago..... <tvon> modern andriond Id say <bkeil> Oh.... <tvon> its the Illuminati <bkeil> I see. <tvon> um...anyways <fkr> should it be called "additional_artist" ? <fkr>* bkeil *ahem*. <tvon> so cool...got guest artist table done...er, yah...additional artist <tvon>* tvon test <tvon> k <tvon> so....what else comes to mind? <tvon> you up for a little more ben? <bkeil> Well.... those were my two big issues. <fkr> what was the second one? <tvon> that and the removal of the artist_album table <fkr> ok. <bkeil> So we should discuss genres. <tvon> ah yes... <fkr> hehe <tvon> genre actually is a sub-set of aother idea <fkr> <tvon> as expressed on the musicbrainz list....... <tvon> and it gets crazy <tvon> but.....lemem give it a shot... <fkr> ben, shall i forward you the mails from the musicbrainz-list? <fkr> (where this is explained) <bkeil> How many are there? <fkr> 4 <bkeil> Sure. <fkr> which mail-address? <bkeil> bkeil@veganpub.com <tvon> ok, I wont try to explain it <tvon> its messy <bkeil> I see. <tvon> but I think it could be great <tvon> the genre idea alone...Ill delve into that so we can discuss it... <tvon> oh, did you see my mail on the list ben? <bkeil> Um... I think so. <tvon> you know what Im talking about? <bkeil> That idea that something could be 75% country and 50% rock'n'roll <fkr> ben, in a minute you'll have em <bkeil> ? <tvon> ah, yes <bkeil> fkr, thanks. <tvon> what did/do you think? <bkeil> Yeah.... it seems pretty good. <tvon> cool.... <fkr> tom, *now* you're glad :) <fkr> hehe <fkr>* tvon grins <tvon> yes, I am <tvon> so, felix.....do you want to skip a step and think about implementing it the way you described ont he musicbrainz list? <fkr> tom, what do you say to that idea? <tvon> (which was, btw, much simpler than I imagined) <bkeil> It seems to me, though, that we should have an "older stlye" genre setting to fall back on. <tvon> of the global relationships? <tvon> yeah, def a old skool genre setup as well.... <fkr> definitly. <fkr> it's just an addition...but tom will explain :) <fkr>* fkr is shortyl afk <tvon> felix, to what idea? on the musicbrainz list? <tvon> ok ben, the global relations thing.... <bkeil> Yeah? <tvon> instead of just the genre setup....you could have relations for everyhitng....so for artists: <tvon> beastie boys = 60% = run dmc <bkeil> I'm not sure I understand.... <tvon> or albums.........and the genre idea turns out to fall into that idea <tvon> so beatie boys are similar to run dmc by 60%..... <tvon> mmm.... <tvon> could relate genres to eachother as well.... <tvon> hip-hop = 70% = rap <tvon> since they are fairly similar to eachother.... <bkeil> 80%, 85%... :) <tvon> yeah...my percentages are educated guesses :-) <tvon> but, you know what I mean? <bkeil> Yessir./ <tvon> the guy that explained it wrote a big ol email about it.... <tvon> waddaya think? <bkeil> As long as I'm not the person developing it.... :) I say, sure. <tvon> the API woudl have to do some work to help it be properly and well implemented... <tvon> lol...yeah <tvon> I almost agree...but I am the person..... <fkr> re <fkr>* bkeil yawns. <bkeil> I'm so bad about sleep these days. <fkr> hehe <fkr> <tvon> oh god...I dont knwo what time or day it is <bkeil> I just built a new machine.... <tvon> ah, cool <bkeil> 1200 MHz Thunderbird w/ 512MB PC 133 RAM <tvon> excellent.... <tvon> I need a new box <tvon> about the relationship table..... <tvon> it would be...:: <bkeil> Ok: <tvon> object_1, object_2, relation, type <tvon> I think <bkeil> What kind of thing is object_1? <tvon> anything...artist, song, genre... <tvon> would play out like:: <tvon> beastie boys | run dmc | 60% | artist <tvon> with artist_id instead of the name of course <bkeil> Hmm.... <tvon> \msg fkr ah...racing fans eh? <fkr> hehe <bkeil> Oopps tvon. <tvon> so, for genre..... <tvon> or the idea I had... <tvon> : <tvon> beastie boys | hip-hop | 50% | genre-aritst <tvon> or something.... <bkeil> beastie boys | run dmc | 60% | artist-artist <tvon> \msg fkr ah..cool <tvon> heh <tvon> that was bound to happen <bkeil> tvon.... try the forward slash... :) <tvon> details details.. <tvon> yeah on the last one ben <tvon> exactly <tvon> and use enum types for the type field <bkeil> Perhaps even more general <tvon> how so? <bkeil> obj1 type1 obj2 type2 relation <tvon> example? <bkeil> beastie boys | artist | run dmc | artist | 60% <tvon> ah <bkeil> beastie boys | artist | hip-hop | genre | 50% <tvon> mm...seems like it would be an extra step in the API to me..... <tvon> cuz we would have to get both type fields, and figure out how they were supposed to relate.... <bkeil> The API could have whatever construct it wanted.... <tvon> the other way, the intended relation would be listed.... <bkeil> Oh... I see what you meen.... <bkeil> Extra step in the library.... more than in the API... <tvon> I swap API/library all the time... <tvon> treat both as the same..... <bkeil> noted. <tvon> so....first way? <tvon> hey felix...where did you go? <fkr> I'm here :) <tvon> ah.....what do you think? <bkeil> Seems ok to me... <fkr> ack. <fkr> makes sense. <tvon> excellent...the [object object relation type] or [object type object type relation] ? <tvon> ok...first one then... <fkr> mmm....the second one leaves more options <fkr>* fkr would go with the second one. <tvon> ah... <fkr> a bit more complex, but way more powerful <tvon> cant we just represent all the type1/type2 setups with a enum? <tvon> they would have to be enum types anyways...why not just one? <tvon>* fkr hardly worked with enums <fkr> dunno. <bkeil> Alternatively, we could have an int for the relation <tvon> heh <bkeil> what's the default int size on mysql and postgres? <tvon> bkeil, what do you mean? <bkeil> the int could be a bitfield <tvon> ben.. <bkeil> ? <fkr> tvon, he wants to save space. <tvon> oh..ok <bkeil> save the first 4 bits for type1, and the second four bits fot type2 <tvon> could it be represented as a percentage? <bkeil> then, we have the flexibity of the two-type system. <tvon> I just think percentages are fairly natural to the mind...when relating things <fkr> http://www.mysql.com/doc/n/o/node_178.html <fkr> http://www.mysql.com/doc/n/o/node_179.html <bkeil> This is just for the internal storage. <fkr> http://www.mysql.com/doc/n/o/node_180.html <tvon> ok, cool <fkr> that's what they take up. <fkr>* tvon wasnt sure what was being talked about <bkeil> It would be | beastie boys | run dmc | 60% | 00010001 <bkeil> with 0001 being binary for artist. <tvon> oh, that works <bkeil> then we also get the advantage of being able to quickly pull all record of a similar type. <tvon> 00010002 for artist-genre? for example? <fkr> ack. <bkeil> Er... 00010010 <fkr> or that. <bkeil> since it is binary... <tvon> oh yes...heh <tvon>* fkr doesn't get that. <tvon> of course <tvon> or fo course as I like to say <fkr> just a small explanation, please. <bkeil> fkr, binary = only 0s and 1s <tvon> dont remember my binary counting...but there is no '2' <bkeil> so 0001 = 1 <fkr> bkeil, know that. <fkr> ok. <fkr> 0010 = 2 then ? <tvon> it does now <tvon> :-) <fkr> 0100 = 3 ? <fkr> did I get it? <bkeil> 0011 <bkeil> 0100 = 4 <fkr> you got an URL for that? <bkeil> 1000 = 8 <tvon> the actual number they represent is not as important as the meaning they represent to us... <tvon> 1000 = album (is what I mean for example) <fkr> I know, much I want to know, how it works....remember...I'm a geek too :) <bkeil> tvon.... you're right... <tvon> ooh, yeah....url url <bkeil> Perhaps.... varchar(2) <tvon> I would love a url about binary translations.....alwyas wanted to know but never looked it up <bkeil> "aa" for artist-artist <bkeil> "ag" for artist-genre <tvon> true <tvon> ad artist-album (disc) <tvon> cuts us short for relations like artist-aardvark artist-antlers artist-apple...etc.... <tvon> I like the binary idea <tvon> its more "geek" too <tvon> and well...geek.....is better...right? <bkeil> Well.... if we use two-letter codes then we get 52*52 possibilites. <tvon> true <tvon>* tvon is still working the whisky out of his system from last night <fkr> we should go with 0's and 1's...saves quiet a bit of space <fkr> we got this table worked out then too? <bkeil> varchar(2) is only 16 bits. <bkeil> what;s the int? <bkeil> 12 bits? <tvon> wiat, what does a enum type take up? <bkeil> probably also 12 bits.... that'd be my guess, anyway.... <tvon> why not to enum? <tvon> how did we get on this anyways? :-) <tvon> though, the table has the potential to be massive.... <bkeil> with a 12-bit int, then we have 32 possible types. <tvon> should make it small as possible.... <tvon> ah <bkeil> no 64 <bkeil> sorry <tvon> hmm.... <bkeil> Or are the ints 11 bits... <bkeil> Then we'd be back down to 32. <fkr> regular ints are 11 <tvon> so varchar(2)? <tvon> seems to leave the widest range of possabilities.... <bkeil> Ok... so 32 types for a regular int, or 52 types for a varchar(2)... <tvon> though Im not sure we would even use 32... <bkeil> Yeah.... What would we be doing that needed 32? <tvon> mmm...artist, album, song, genre.......whats the count? <tvon> reltae to selves and each of the others... <bkeil> Well..... 32 is the count for each ting relating to all other possible things, that is, <bkeil> 32 for type 1 and 32 for type2 <tvon> heh... <fkr> hehe..../me is lost :) <tvon> yeah...arent we using the single type table? <tvon> or am I just thick headed? <bkeil> Yes. <bkeil> Yes. Single type made out of two types <tvon> so a single type...we need exaclty 32.... <tvon> oh... <tvon> aa, ag etc right? <tvon> yeah.... <bkeil> basically TYPE = type1 * 32 + type2 for the ints <tvon> that one lost me <bkeil> OK.... <bkeil>* tvon grins <bkeil> 0000100000 = 32 <tvon> yah <bkeil> 0000100001 = 33 <tvon> oh...ok <bkeil> So for artist artist we have 33, if artist=1 <tvon> and what is wrong with using enum? ARTIST-ALBUM ARTIST_GENRE...? <bkeil> for album artist we have 0001000001 = 65 if album=2 and artist=1 <bkeil> enums are basically ints <tvon> album=2? <tvon> artist=1? <tvon> OH..ok..skip that <bkeil> 32 * 2 + 1 = 65 <tvon> so, dosent enum just assign a sort of hidden int to the value? <bkeil> Yeah... *** SWAP: No such window: 67*** SWAP: No such window: 67 <tvon> artist-album = 0, artist-genre = 2.... <bkeil> we could do it that way.... I'm not strongly opposed. <tvon> dosent [postge|my]sql support enum types for fields? <tvon> thought someone said that...though I wouldnt know how to do it... <tvon> oh.... <bkeil> I was just suggesting a way in which we could organize that 11 bit space.\ <tvon> oh... <tvon> felix? <fkr> yes.. :) <tvon> what do you think? <bkeil> an enum of ARTIST-GENRE ALBUM-GENRE..... I'd be okay with that... <tvon> ok... <tvon> lets go with that for now... :-) <fkr> tvon, I'm about 30 thoughts behind you guys :) <fkr>* fkr is ashamed. <tvon> I was getting lost with all the type discussion.....if we can do something small....great..... <tvon> oh, dont worry.... <bkeil> It's just that the other way, we automatically get all the possible relationships we want without having to think them through before hand. <tvon> I wont retain any of this for more than 30 minutes anyways.... <tvon> hence the logs <tvon> oh....OH...ok <tvon> well, that is a good idea <tvon> :-) <tvon> one thing, I would like to leave room for non artist/album/song/genre relationships should we discover any <tvon> and with enum we could just add them...... <bkeil> I'm not sure how easy it is to change an enum field in an existing database. <tvon> true <tvon>* tvon tends to think in C <bkeil> With the binary solution, we already have 32 types in place, all we have do do is define one that hasn't been defined yet. <tvon> ok... <tvon> lets go binary then <bkeil> think "type1<<5 + type2" <tvon> nod <tvon> so what is the mysql type for the field? <fkr> int <bkeil> int(11) <tvon> k <tvon> so we just assign something like 0001 = artist 0010 = album...etc...and we have up to how far? <tvon>* tvon apologizes for needing it spelled out <fkr> a lot. <fkr>* tvon blows the dust off of K&R <tvon> excellent <tvon> golden... <bkeil> We get 32 types.... we can define 0 = whatever, 1 = whatever, 2 = whatever, until we've run out of things to assign to numers. <tvon> so we have that table done... <bkeil> When we run out, it doesn't matter. <tvon> I am going to point that Hans fellow to the png up at the site..... <bkeil> If we only come up with 6 things now, that leaves us 26 things for the future. <tvon> excellent <fkr> is either one of you adding these two tables to our dia-files? <tvon> ah, no... <bkeil> I'm not currently running dia. <tvon> dia kicks ass <tvon> btw... <fkr> ok, I'll then. <tvon> but....ok, great <tvon> I am going to finish up the "project status" page.... <tvon> or the content of it anywyas.... <bkeil> I'm going to take a shower. <bkeil> :) <tvon> :-) <tvon> alright, I feel we accompished a good amount here <fkr> tom, before you point him out the png-thingies, generate new ones. <tvon> yeah, I will... <tvon> mm....Ill catch your cvs commit and do it then... <fkr> you probably saw my commits. <tvon> then Ill drop him a line <tvon>* bkeil waves. It's been real, and it's been fun.... <fkr> cu ben. <tvon> cya Ben...thanks for stopping by.. *** Signoff: bkeil (Client Exiting)*** Signoff: bkeil (Client Exiting) <fkr> <tvon> yup <tvon> :-) <fkr> so how's your head? <tvon> its good... <tvon> I deal well after a few hours <tvon> I usually sleep through the headache....woke up early <fkr> somehow I had headache all day long today. <tvon> was afraid I would sleep through the IRC time :-) <tvon> ah, lame <fkr> how about this parsing thing... <tvon> oh yes...thanks... <fkr> i didn't quiet understand what you meant. <tvon> it spits out the head stuff.... <tvon> well... <tvon> A) gaby dosent support user specific plugins that override the gloabl ones <tvon> b) I dont want to edit the global one to be specific for thie project <fkr> oic <tvon> so....if you could parse out the header stuff (I got it all on one line...so its just the first line) <tvon> oh.....yeah...wait.... <tvon> I could write a sed script to do that..... <fkr> even better :) <tvon> so.....dunno...any automatic way to do it? <fkr> cron-job? <tvon>content-todo.php <tvon> or status... <tvon> cron...actually... <tvon> since it will be updated when I export it from gaby...I can just run the script <tvon> since I have to export it anyways..... <fkr> ack. <tvon> so, thats taken care of....what else..... <fkr> hmmm.. <fkr> I'm going to update the schema <tvon> what did I mail you about? just that and the Hans fellow? <tvon> oh, can you send me a html of this log? <fkr> going to convert some datatypes so that the schema will work with mysql and postgresql <tvon> ok, excellent <tvon> Ill edit out the openprojects messages and whatnot..... <fkr> and write another patch for dia2sql. <tvon> (in the log) <tvon> oh yeah...excellent work on that.... <tvon> is very nice to be able to generate from dia <fkr> that darned author never replied two me. <tvon> ah....lame <fkr> s/two/to/ <tvon> another zombie project <tvon> or orphan.... <tvon> always confuse the two processes... <fkr> I'll add it to the patches-cvs-module (that's how I got the idea) and maintain an version for us. <tvon> excellent.... <tvon> do we have a limit on cvs space? <fkr> don't worry :) <tvon> yeah, know we are nto close.... <fkr> there are other *huge* projects on cvs at sourceforge (like python etc.) <tvon> but for that one, might as well just throw in the whole thing in cvs...instead o fjust the patch <tvon> s/o fjust/of just/ <fkr> it will be easier with patches if he (author) ever releases a new version <tvon> ah, true <tvon>* fkr loves patches :) <tvon>* tvon dosent know what he would do without Felix working on the SMDP <tvon> :-) <fkr> thanks :) <tvon> my man in german <tvon> y <fkr> it's fun though <tvon> good <tvon> cuz its going to get alot more "fun" before too long <tvon> :-) <fkr> hehe <fkr> how often do you update the website at sourceforge? <tvon> when the cvs is clean and presentable....always.... <tvon> right now I think the index page is funky...or maybe that just my local copy <fkr> what happened? <tvon> ooh....might not have updated since some of your translation changes.... <tvon> it works...Im editing the opening paragraph... <tvon> it was weak <tvon> and, since the languages and databases are covered in the faq, I am removing them from the opening paragraph.....was going to ask you about that though.....think its good? <tvon> (smdp.etria.org is what Im working on..) <tvon> (if you want to see) <fkr> looks good. <tvon> I figure the faq should hold info on what languages and datagbases we support....and then I figure if its in the faq we dont need it on the main page ...... <fkr> ack. ack. ack. :) <tvon> nod nod nod <tvon> cools <tvon> alright then... <tvon> Im goign to work on that...and the todo stuff and the sed script....and ... <fkr> oh, one more question: <tvon> ok <fkr> who is the other guy on the smdp-devel@ list with an etria.org address? <tvon> oh...my friend brion.... <tvon> briOn not briAn... <tvon> shrug <fkr> oic <tvon> is a friend who asked to be put on the list....his address was broken so he used his account on my box... <fkr> wondered as I looked at the mailman-page <tvon> ah..yeah... <fkr> was nice talking to you again :) <tvon> yeah...he reads the list a bit...not very involved though... <tvon> yeah... <fkr> I hope that holger@ get's involved... <tvon> oh, so tell me when you get the dia updated.....and send me the html log of this if you please.... <tvon> yeah...vinz sent me a mail saying he wanted to be here but was busy...... <fkr> first I'll send you a txt-version of the log. <tvon> ok <tvon> (I downloaded that IRCstats thing but didnt get it setup in time btw) <fkr> ok....I'm off doing work then :) <tvon> ok...excellent.. <fkr> .oO I'll stay here but will be working :) <tvon> will speak to you soon :-) <tvon>