<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
<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> 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
<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
<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)
<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> 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 :-)