One of the goals of Koala is to be as lightweight as Facebook's own
official libraries (i.e. PHP SDK, Python SDK) so all of the calls (for
the most part) return the raw data from Facebook in an easily
consumable interface (in Ruby's case, hashes.) A lot of the GraphAPI
module methods actually mimic methods in those libraries.
I'm tempted to say that object wrappers for each type of object isn't
necessarily on the road map for Koala at this point. This would
detract from the lightness of the library for users who, for example,
only need to access user objects but have to additionally download
class files for all of the other types of objects in the graph.
That being said, there are cases where having Ruby objects for nodes
in the graph would be useful, as you pointed out. Instead of a fork,
I would suggest building a library on top of Koala so that, as the
object library matures, it could be offered as a Koala plug-in/add-
on. Basically, a distinct gem that would just require the koala gem.
This way, those who don't want/need the objects can just use the Koala
gem, while those who want more, could additionally install this new
gem as well. I haven't thought through it all the way, but it seems
like that would be a nice way to keep this new library more resilient
from Koala core changes.
Chris