On Fri, Feb 3, 2012 at 6:07 PM, André Kelpe
> 2012/2/3 Claudio Martella <claudio.marte...@gmail.com>:
>> Hi Andre,
>> As I see it, we'd basically have to move all the API about edges from
>> single object to Iterable (i.e. returning multiple edges for a given
>> vertex endpoint as you suggested), and maybe also returning multiple
>> vertices for a given edge(label).
> If the goal of giraph is to be close to the pregel paper, then that
> kind of API makes
> more sense.
>From how I see it, we've already taken a distance from Pregel in many
API decisions. Personally I believe we don't have to stick to Pregel,
we definitely have just to design Giraph for it's useful. For what we
know, the API of the paper could be just the smallest subset of the
real Pregel API that could fit clearly into the paper.
> I am going to look into your code and see if I can
> integrated it in the
> copy of giraph I use internally here right now.
Be ware that the code is not meant for general purpose but for a
specific task. The "extended" api methods though should be quite
>> The single-graph, as it's implemented now compared to multi-graph,
>> would be a subcase of this which internally it would return
> That would mean, you'd have two different kinds of vertex, one
> compatible with single-graphs
> and one with multi-graphs. Sounds tricky to maintain on the long run,
> but could be an idea.
I see the single-graph vertex as a subclass of the multi-graph vertex,
something along with what's already going on with mutablevertex, so i
don't see a problem in maintaining it.
> André (@fs111)