[Rbrainz-users] Do you need help.
nigel at maven-group.org
Thu Jun 7 05:35:27 EDT 2007
Philipp Wolfer wrote:
> Hi Nigel,
> that sounds really interesting. Yes, I sure could use some help. I
> think it would be a good idea if we would combine our efforts.
>> I have actually allready written an unpublish Ruby port of the
>> MusicBrainz WebService2 Python API and am currently working on ruby
>> bindings for TunePimp.
> If you like you could take a look at the current version of RBrainz in
> Subversion (see http://rubyforge.org/scm/?group_id=3677) which support
> querying collections as well. Maybe we can combine the two projects to
> have the best of both. Even though RBrainz generally follows the
> Python implementation there are some differences:
My implementation follows the python implementation almost to the
letter. I looked at yours and it differs alot more from the python one.
Thats also why I think it would be easier if we just took your code and
worked from that base.
I do have some comments to your usage of 'is_a'. I personally prefer
using duck typing instead.
> 1. There is a own class MBID for MusicBrainz IDs
As I mentioned earlier I am not such a big fan of using tests on the
class type. I have attached a duck typing edition of MBID for you to
look at and comment on.
> 2. There is a class IncompleteDate to better support the date format
> used by MusicBrainz
I like that you have wrapped the incomplete dates. But I do have a
Based on previous experience with incomplete/partial dates I have found
it usefull to consider them as time periods. This way of looking at them
considerably lightens the burden of dealing with them with regards to
other data types like Time and Date. Another advantage is that periods
have a string of well defined operations that makes it so much easier to
to do stuff like finding bands that were active from 1979 - 1999.
> 3. Search results are returned in a own Collection object and not just
> a plain array. This gives access to some additional features like the
> result's score.
> 4. The class to parse the XML is completely different
>> I was thinking of trying to compile a OS-X universal binary of MB-DiscID
>> later tonight.
> Great, let me hear of the result. Currently MB-DiscID lacks a proper
> rake task to build binary packages, but there is some rudimentary
> support to automate Win32 package creation (take a look at the
> Rakefile, you will see it).
> By the way: I checked in some changes to MB-DiscID into the SVN the
> last days, but there is not that much difference to the current
> release (mainly support for the "put" method and a fix for a possible
> core dump).
The gem compiled and installed fine on my Mac. As for binary package
generation it's a bit more challenging since Mac binaries come in 3
variants; PowerPC, Intel and fat universal binaries that contain one or
more binaries in a single file. The problem with ruby extensions on mac
are that they are of the same binary variant as the ruby version used to
run rake and when doing binary distribution it's considered good
practice to make universal binaries.
Another problem is that Gem::Platform doesn't reflect this 3 binary
system. Gem::Platform::DARWIN contains the string 'powerpc-darwin' which
is only the right value for PowerPC binaries.
> I won't have much time the next 3 weeks, so don't expect much action
> on the project in this time. When I'm back again I will prepare the
> next releases of MB-DiscID and RBrainz.
> I would suggest we will talk about details when I'm fully available
> again. I will read my mails in the meantime not very frequently, so it
> will probably take some time until mails get answered.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 163 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/rbrainz-users/attachments/20070607/94c1ff11/attachment.vcf
More information about the Rbrainz-users