giraph-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Avery Ching <ach...@apache.org>
Subject Re: multi-graph support in giraph
Date Fri, 03 Feb 2012 19:10:54 GMT
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.

Avery

On 2/3/12 9:14 AM, Claudio Martella wrote:
> On Fri, Feb 3, 2012 at 6:07 PM, André Kelpe
> <efeshundertelf@googlemail.com>  wrote:
>> 2012/2/3 Claudio Martella<claudio.martella@gmail.com>:
>>> Hi Andre,
>> Hi!
>>
>>> 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
> general.
>
>>> The single-graph, as it's implemented now compared to multi-graph,
>>> would be a subcase of this which internally it would return
>>> getEdgeValue().iterator().next().
>> 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)
>
>


Mime
View raw message