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
2012/2/3 Claudio Martella<claudio.marte...@gmail.com>:
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
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.