We can diverge from the Pregel API as long as we have a good reason for it. I do agree that while we can support multi-graphs with a user-chosen edge type, some built-in support that makes programming easier sounds like a good goal. Andre or Claudio, feel free to open a JIRA to discuss this.

We should also figure out the appropriate APIs as well that make it the most convenient to use.


On 2/3/12 9:14 AM, Claudio Martella wrote:
On Fri, Feb 3, 2012 at 6:07 PM, André Kelpe
<efeshundert...@googlemail.com>  wrote:
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)

Reply via email to