From phw at rubyforge.org Wed Jul 4 15:51:04 2007 From: phw at rubyforge.org (Philipp Wolfer) Date: Wed, 4 Jul 2007 21:51:04 +0200 Subject: [Rbrainz-users] MB-DiscID 0.1.2 released Message-ID: Version 0.1.2 of MB-DiscID has been released. MB-DiscID provides Ruby bindings for the MusicBrainz DiscID library libdiscid. It allows you to calculate MusicBrainz DiscIDs from audio CDs which you can use to find the release entry for your CD in the MusicBrainz database. This is a stable release. It includes all functions provided by libdiscid. For an example on how to use MB-DiscID see the API documentation on http://rbrainz.rubyforge.org/mbdiscid/api/ or the file example/discid.rb included in the package. More information: http://rbrainz.rubyforge.org API-Documentation: http://rbrainz.rubyforge.org/mbdiscid/api/ Changes in this release: * Support the method put to set the TOC information directly instead of reading it from a device. * Fixed possible core dump if read was called twice and failed the second time. * New to_s method (returns string representation of the ID itself). * Complete RDoc documentation. -- Philipp Wolfer From phw at rubyforge.org Sun Jul 8 15:28:55 2007 From: phw at rubyforge.org (Philipp Wolfer) Date: Sun, 8 Jul 2007 21:28:55 +0200 Subject: [Rbrainz-users] InvalidDate questions Message-ID: Hi Nigel, I just had the time to look at the InvalidDate, great. Just two quick questions: 1. What is the pp module in euqality.rb doing? 2. Do we need a separate implementation of eql?, since Range already implements this? Best regards, Phil -- Philipp Wolfer From phw at rubyforge.org Mon Jul 9 04:35:51 2007 From: phw at rubyforge.org (Philipp Wolfer) Date: Mon, 9 Jul 2007 10:35:51 +0200 Subject: [Rbrainz-users] Fwd: [mb-devel] libmusicbrainz 3.0.1 released In-Reply-To: <1183962995.6296.19.camel@nemo> References: <1183962995.6296.19.camel@nemo> Message-ID: Some information from MusicBrainz: The MusicBrainz team has released a new version 3.0.1 of the C libmusicbrainz library. With this release they add support for newer MusicBrainz features. Since RBrainz was developed from the beginning with those features in mind the changes in the new libmusicbrainz are already implemented in RBrainz. For those who are interested the official release announcement can be found at http://lists.musicbrainz.org/pipermail/musicbrainz-devel/2007-July/002203.html -- Philipp Wolfer -------------- next part -------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBGkddzOjmgKpITL3sRAmtzAJwIyqcvXKoVvoJpxMjLmrhEfButtwCfVUzl 98e7NQvSGAY8q8PSiGDJ0eM= =bRbF -----END PGP SIGNATURE----- From nigel at maven-group.org Mon Jul 9 05:23:14 2007 From: nigel at maven-group.org (Nigel Graham) Date: Mon, 09 Jul 2007 11:23:14 +0200 Subject: [Rbrainz-users] InvalidDate questions In-Reply-To: References: Message-ID: <4691FE82.3010304@maven-group.org> Hi Philipp, The pp module is a leftover from some test code, I have removed it now. Why do you think it needs a different eql? The one in range wil work for both incomplete dates and ranges and since we treat IncompleDate as a special kind of Range I don't see a problem. What could be confusing though is if we have 2 different value comparisons. (== and eql?). Mfg. Nigel Philipp Wolfer wrote: > Hi Nigel, > > I just had the time to look at the InvalidDate, great. Just two quick questions: > > 1. What is the pp module in euqality.rb doing? > 2. Do we need a separate implementation of eql?, since Range already > implements this? > > Best regards, > Phil > > -------------- next part -------------- A non-text attachment was scrubbed... Name: nigel.vcf Type: text/x-vcard Size: 163 bytes Desc: not available Url : http://rubyforge.org/pipermail/rbrainz-users/attachments/20070709/29e30d12/attachment.vcf From phw at rubyforge.org Mon Jul 9 05:33:15 2007 From: phw at rubyforge.org (Philipp Wolfer) Date: Mon, 9 Jul 2007 11:33:15 +0200 Subject: [Rbrainz-users] InvalidDate questions In-Reply-To: <4691FE82.3010304@maven-group.org> References: <4691FE82.3010304@maven-group.org> Message-ID: > Why do you think it needs a different eql? The one in range wil work for > both incomplete dates and ranges and since we treat IncompleDate as a > special kind of Range I don't see a problem. What could be confusing > though is if we have 2 different value comparisons. (== and eql?). No, I just wondered why we need to re-implement eql? since it is already defined in Range. See http://www.ruby-doc.org/core/classes/Range.html#M000705. But as I see now the difference is that the original Range only accepts other Range objects for comparison while you implementation allows other types as well. I hope we don't break anything in other's people code when we overwrite eql? -- Philipp Wolfer From nigel at maven-group.org Mon Jul 9 06:04:09 2007 From: nigel at maven-group.org (Nigel Graham) Date: Mon, 09 Jul 2007 12:04:09 +0200 Subject: [Rbrainz-users] InvalidDate questions In-Reply-To: References: <4691FE82.3010304@maven-group.org> Message-ID: <46920819.7030003@maven-group.org> Philipp Wolfer wrote: >> Why do you think it needs a different eql? The one in range wil work for >> both incomplete dates and ranges and since we treat IncompleDate as a >> special kind of Range I don't see a problem. What could be confusing >> though is if we have 2 different value comparisons. (== and eql?). >> > > No, I just wondered why we need to re-implement eql? since it is > already defined in Range. See > http://www.ruby-doc.org/core/classes/Range.html#M000705. > > Oh thats what you mean. Actually my implementation accepts both Ranges and scalars (meaning the value types used for the endpoints of the range). When it gets a Range it acts just like the existing implementation in Range but when it gets a scalar like 1 it treats it as a range with a length of 1. > But as I see now the difference is that the original Range only > accepts other Range objects for comparison while you implementation > allows other types as well. I hope we don't break anything in other's > people code when we overwrite eql? > > -------------- next part -------------- A non-text attachment was scrubbed... Name: nigel.vcf Type: text/x-vcard Size: 163 bytes Desc: not available Url : http://rubyforge.org/pipermail/rbrainz-users/attachments/20070709/bb3b631b/attachment.vcf From nigel at maven-group.org Mon Jul 9 07:05:10 2007 From: nigel at maven-group.org (Nigel Graham) Date: Mon, 09 Jul 2007 13:05:10 +0200 Subject: [Rbrainz-users] InvalidDate questions In-Reply-To: <46920819.7030003@maven-group.org> References: <4691FE82.3010304@maven-group.org> <46920819.7030003@maven-group.org> Message-ID: <46921666.7070309@maven-group.org> Nigel Graham wrote: > Philipp Wolfer wrote: >>> Why do you think it needs a different eql? The one in range wil work >>> for >>> both incomplete dates and ranges and since we treat IncompleDate as a >>> special kind of Range I don't see a problem. What could be confusing >>> though is if we have 2 different value comparisons. (== and eql?). >>> >> >> No, I just wondered why we need to re-implement eql? since it is >> already defined in Range. See >> http://www.ruby-doc.org/core/classes/Range.html#M000705. >> >> > Oh thats what you mean. Actually my implementation accepts both Ranges > and scalars (meaning the value types used for the endpoints of the > range). > When it gets a Range it acts just like the existing implementation in > Range but when it gets a scalar like 1 it treats it as a range with a > length of 1. Further reading and testing just showed me that the above statement isn't entirely correct. First of my implementation of eql? never made it into Range since the eql? defined in Range tok precedent over the one I defined in the module. So I have now fixed this. Second my implementation when comparing two Ranges doesn't do the same as the builtin one. The builtin eql? considers 1..12 and 1...13 as two different ranges. Mine considers them equal since they span the same values. > >> But as I see now the difference is that the original Range only >> accepts other Range objects for comparison while you implementation >> allows other types as well. I hope we don't break anything in other's >> people code when we overwrite eql? >> >> > > _______________________________________________ > Rbrainz-users mailing list > Rbrainz-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rbrainz-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: nigel.vcf Type: text/x-vcard Size: 163 bytes Desc: not available Url : http://rubyforge.org/pipermail/rbrainz-users/attachments/20070709/b0b0640c/attachment.vcf From phw at rubyforge.org Tue Jul 10 04:11:22 2007 From: phw at rubyforge.org (Philipp Wolfer) Date: Tue, 10 Jul 2007 10:11:22 +0200 Subject: [Rbrainz-users] MB Metadata Schema 1.2 Message-ID: Two weeks ago a new version 1.2 of the MB Metadata Schema was published. See http://bugs.musicbrainz.org/browser/mmd-schema/trunk/schema. New is the support for label aliases and tagging support for artists, labels, releases and tracks. Both should be easy to implement in RBrainz. I will add the label alias support soon. At the moment I don't know much about the tags and how it is planned to be used or when it will be available in MusicBrainz. -- Philipp Wolfer From nigel at maven-group.org Tue Jul 10 06:25:48 2007 From: nigel at maven-group.org (Nigel Graham) Date: Tue, 10 Jul 2007 12:25:48 +0200 Subject: [Rbrainz-users] MB Metadata Schema 1.2 In-Reply-To: References: Message-ID: <46935EAC.3070502@maven-group.org> I just looked at the new schema. It seems that user-list is not part of that schema or rather it is belongs under the extension part of the schema which is basicly a match everything. Philipp Wolfer wrote: > Two weeks ago a new version 1.2 of the MB Metadata Schema was > published. See http://bugs.musicbrainz.org/browser/mmd-schema/trunk/schema. > > New is the support for label aliases and tagging support for artists, > labels, releases and tracks. Both should be easy to implement in > RBrainz. > > I will add the label alias support soon. At the moment I don't know > much about the tags and how it is planned to be used or when it will > be available in MusicBrainz. > > -------------- next part -------------- A non-text attachment was scrubbed... Name: nigel.vcf Type: text/x-vcard Size: 163 bytes Desc: not available Url : http://rubyforge.org/pipermail/rbrainz-users/attachments/20070710/6870ff33/attachment.vcf From nigel at maven-group.org Tue Jul 10 06:41:34 2007 From: nigel at maven-group.org (Nigel Graham) Date: Tue, 10 Jul 2007 12:41:34 +0200 Subject: [Rbrainz-users] Current mbxml implementation and user query. Message-ID: <4693625E.90500@maven-group.org> Hi, I've been fiddling a little with the user query (It seemed the easiest way to test my user authentication). I have run into a little snag. The mbxml implementation doesn't fit that well with user query. Or maybe it would be more appropriate to say that user query breaks the mold on how queries are done. 1. User query result is returned in a 'user-list' even though there is never more than 1 entry. 2. The three tags 'user-list', 'user' and 'nag' are all in the NS_EXT_1 namespace. 3. The user(s) in the user-list don't have a score. :-( On the bright side user authentication works. Mfg. Nigel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rbrainz-users/attachments/20070710/c5d69774/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: nigel.vcf Type: text/x-vcard Size: 163 bytes Desc: not available Url : http://rubyforge.org/pipermail/rbrainz-users/attachments/20070710/c5d69774/attachment-0001.vcf From phw at rubyforge.org Tue Jul 10 07:45:59 2007 From: phw at rubyforge.org (Philipp Wolfer) Date: Tue, 10 Jul 2007 13:45:59 +0200 Subject: [Rbrainz-users] Current mbxml implementation and user query. In-Reply-To: <4693625E.90500@maven-group.org> References: <4693625E.90500@maven-group.org> Message-ID: > User query result is returned in a 'user-list' even though there is never > more than 1 entry. > The three tags 'user-list', 'user' and 'nag' are all in the NS_EXT_1 > namespace. > The user(s) in the user-list don't have a score. :-( We could of course make this a special case (maybe a special get_user method in MBXML). But maybe there is a more generic way. Did you have a look how pythonmusicbrainz handles those requests? -- Philipp Wolfer From phw at rubyforge.org Tue Jul 10 08:28:44 2007 From: phw at rubyforge.org (Philipp Wolfer) Date: Tue, 10 Jul 2007 14:28:44 +0200 Subject: [Rbrainz-users] MB Metadata Schema 1.2 In-Reply-To: <46935EAC.3070502@maven-group.org> References: <46935EAC.3070502@maven-group.org> Message-ID: 2007/7/10, Nigel Graham : > I just looked at the new schema. It seems that user-list is not part of > that schema or rather it is belongs under the extension part of the > schema which is basicly a match everything. Just some ideas I had about extensions when I started to write RBrainz. Perhaps doesn't really apply to user. The extensions are one of the best features of the MB XML specification. Since there can be arbitrary extensions RBrainz itself should be easily extensible. Ruby should make it easy since it allows the modification of already defined classes. So my idea was to put extensions into separate file(s) and allow the user to load just the extensions he needs. -- Philipp Wolfer From nigel at maven-group.org Tue Jul 10 10:15:13 2007 From: nigel at maven-group.org (Nigel Graham) Date: Tue, 10 Jul 2007 16:15:13 +0200 Subject: [Rbrainz-users] MB Metadata Schema 1.2 In-Reply-To: References: <46935EAC.3070502@maven-group.org> Message-ID: <46939471.6020704@maven-group.org> Philipp Wolfer wrote: > 2007/7/10, Nigel Graham : > >> I just looked at the new schema. It seems that user-list is not part of >> that schema or rather it is belongs under the extension part of the >> schema which is basicly a match everything. >> > > Just some ideas I had about extensions when I started to write > RBrainz. Perhaps doesn't really apply to user. > > The extensions are one of the best features of the MB XML > specification. Since there can be arbitrary extensions RBrainz itself > should be easily extensible. Ruby should make it easy since it allows > the modification of already defined classes. So my idea was to put > extensions into separate file(s) and allow the user to load just the > extensions he needs. > As far as I know right now the only extension available is the user query. And it seems a little much to design an extension mechanism just for one call. Another thing is that we don't know what kind of extensions will be made available or how they might work. -------------- next part -------------- A non-text attachment was scrubbed... Name: nigel.vcf Type: text/x-vcard Size: 163 bytes Desc: not available Url : http://rubyforge.org/pipermail/rbrainz-users/attachments/20070710/24fce61b/attachment.vcf From nigel at maven-group.org Tue Jul 10 11:10:58 2007 From: nigel at maven-group.org (Nigel Graham) Date: Tue, 10 Jul 2007 17:10:58 +0200 Subject: [Rbrainz-users] Current mbxml implementation and user query. In-Reply-To: References: <4693625E.90500@maven-group.org> Message-ID: <4693A182.405@maven-group.org> Philipp Wolfer wrote: >> User query result is returned in a 'user-list' even though there is never >> more than 1 entry. >> The three tags 'user-list', 'user' and 'nag' are all in the NS_EXT_1 >> namespace. >> The user(s) in the user-list don't have a score. :-( >> > > We could of course make this a special case (maybe a special get_user > method in MBXML). But maybe there is a more generic way. Did you have > a look how pythonmusicbrainz handles those requests? > > I ended up making a get_entity_array method that returns a normal array instead of a Collection object. I also made some of the methods take an extra namespace argument so they could be used for user queries. Mfg. Nigel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rbrainz-users/attachments/20070710/556c9870/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: nigel.vcf Type: text/x-vcard Size: 163 bytes Desc: not available Url : http://rubyforge.org/pipermail/rbrainz-users/attachments/20070710/556c9870/attachment.vcf From phw at rubyforge.org Tue Jul 10 12:08:04 2007 From: phw at rubyforge.org (Philipp Wolfer) Date: Tue, 10 Jul 2007 18:08:04 +0200 Subject: [Rbrainz-users] MB Metadata Schema 1.2 In-Reply-To: <46939471.6020704@maven-group.org> References: <46935EAC.3070502@maven-group.org> <46939471.6020704@maven-group.org> Message-ID: 2007/7/10, Nigel Graham : > As far as I know right now the only extension available is the user > query. And it seems a little much to design an extension mechanism just > for one call. > Another thing is that we don't know what kind of extensions will be made > available or how they might work. I know, that's why I thought that this doesn't apply to the user extension (and because I believe the user extension should be part of the libraries core anyway). I'm against designing a complete extension mechanism, I just have the hope that such a mechanism should not be to complicated due to the possibilities in Ruby. Essential would be to be able to extend the MBXML class. Let's see how extension in MB will develop in the future. -- Philipp Wolfer From phw at rubyforge.org Tue Jul 10 15:46:46 2007 From: phw at rubyforge.org (Philipp Wolfer) Date: Tue, 10 Jul 2007 21:46:46 +0200 Subject: [Rbrainz-users] Current mbxml implementation and user query. In-Reply-To: <4693A182.405@maven-group.org> References: <4693625E.90500@maven-group.org> <4693A182.405@maven-group.org> Message-ID: 2007/7/10, Nigel Graham : > I ended up making a get_entity_array method that returns a normal array > instead of a Collection object. > I also made some of the methods take an extra namespace argument so they > could be used for user queries. We have authentication, that's great :-) I just wondered why this get_entity_array is needed. I replaced it by a call to get_entity_list and extracted the user from the collection. The missing scores shouldn't be a problem since MBXML sets it to nil if not set. While doing the changes I noticed that I don't like the interface of Query very much. You always have to create filter or include objects to pass them to the methods. The filters and includes are internally useful and provide the capability to extend the filters/includes. Query however should be an easy to use interface to the webservice. Most time it would be sufficient and more convenient to pass the filter hash directly to the methods in Query. What do you think? Best regards, Phil -- Philipp Wolfer From phw at rubyforge.org Mon Jul 16 04:46:44 2007 From: phw at rubyforge.org (Philipp Wolfer) Date: Mon, 16 Jul 2007 10:46:44 +0200 Subject: [Rbrainz-users] Model factory Message-ID: Hi Nigel, I added a factory class for the models. It works mostly as in PythonMusicbrainz with the following differences: * DefaultFactory is defined in the Model module. * There is a method new_entity to create an entity class for a given entity type. There are a few open points I like to discuss: 1. Currently all custom entity classes need to implement entity_type, since the generic version in Entity uses the class name to return the entity type. I like to get rid of this but keep the method. I thought about setting the type in the constructor. 2. What do you think about refactoring Query.new to only accept the options hash (currently webservice is a separate parameter) 3. Do you think the factory should be able to construct Collections as well? I think it would be a good idea 4. Does it need to create IncompleteDate and MBID? I think those are basic data types which don't need to be created by a factory. Regards, Phil -- Philipp Wolfer From phw at rubyforge.org Thu Jul 19 14:33:08 2007 From: phw at rubyforge.org (Philipp Wolfer) Date: Thu, 19 Jul 2007 20:33:08 +0200 Subject: [Rbrainz-users] RBrainz 0.2.0 released Message-ID: Version 0.2 of RBrainz, a Ruby library to access the MusicBrainz web service, has been released. With this release all of the features provided by the MusicBrainz web service are supported. The most notable changes from the previous beta releases are: * Querying of collections * User authentication and querying of user information * PUID submission * Support for label aliases * Complete support of the MusicBrainz metadata scheme 1.2 (including the upcoming tagging) A complete list of changes can be found at http://rubyforge.org/frs/shownotes.php?release_id=13094 I like to thank Nigel Graham who joined development and implemented important parts of the library. Without him this complete release wouldn't have been so early possible. For more information about RBrainz see the following resources: Homepage: http://rbrainz.rubyforge.org API documentation: http://rbrainz.rubyforge.org/api/ Download: http://rubyforge.org/frs/?group_id=3677 -- Philipp Wolfer From phw at rubyforge.org Fri Jul 20 03:32:36 2007 From: phw at rubyforge.org (Philipp Wolfer) Date: Fri, 20 Jul 2007 09:32:36 +0200 Subject: [Rbrainz-users] RBrainz on MusicBrainz Message-ID: Robert Kaye put us on the MusicBrainz blog: http://blog.musicbrainz.org/archives/2007/07/release_of_rbra.html -- Philipp Wolfer From phw at rubyforge.org Tue Jul 24 14:01:41 2007 From: phw at rubyforge.org (Philipp Wolfer) Date: Tue, 24 Jul 2007 20:01:41 +0200 Subject: [Rbrainz-users] RBrainz 0.2.1 released Message-ID: RBrainz 0.2.1 has been released. This is a bugfix release which mainly solves two parsing problems which occurred when querying musicbrainz.org. See the changelog at http://rbrainz.rubyforge.org/api/files/CHANGES.html for details. For more information about RBrainz see the following resources: Homepage: http://rbrainz.rubyforge.org API documentation: http://rbrainz.rubyforge.org/api/ Download: http://rubyforge.org/frs/?group_id=3677 -- Philipp Wolfer