flink-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ufuk Celebi <...@apache.org>
Subject Re: [DISCUSS] Spargel vs. Gelly
Date Fri, 10 Apr 2015 11:45:22 GMT
Thanks for the links, Vasia! I forgot about this.

Consensus is to deprecate and remove after Gelly is out of staging then. :-)

On Fri, Apr 10, 2015 at 12:41 PM, Vasiliki Kalavri <
vasilikikalavri@gmail.com> wrote:

> Hey!
>
> We've had this discussion before actually [1] and we also have a JIRA to
> deprecate Spargel [2] :-)
> I agree that we should keep Spargel deprecated until Gelly is out of
> staging.
>
> Cheers,
> -Vasia.
>
> [1]: https://www.mail-archive.com/dev@flink.apache.org/msg01218.html
> [2]: https://issues.apache.org/jira/browse/FLINK-1693
>
> On 10 April 2015 at 12:22, Stephan Ewen <sewen@apache.org> wrote:
>
> > I would remove Spargel at some point in time, but not until Gelly is out
> of
> > staging.
> >
> > On Fri, Apr 10, 2015 at 12:13 PM, Ufuk Celebi <uce@apache.org> wrote:
> >
> > > Hey all,
> > >
> > > currently we have two vertex-centric graph APIs: Spargel and Gelly. I
> > want
> > > to discuss whether we shall
> > > 1) keep Spargel as a public API as it is, or
> > > 2) deprecate (and remove) it.
> > >
> > > In my understanding, Spargel was a proof-of-concept, which stuck
> around.
> > > It is very stable, but limited in functionality. Gelly provides a
> > superset
> > > of Spargel's functionality and a high-level library of graph
> algorithms.
> > > The vertex-centric iterations actually wrap Spargel.
> > >
> > > I am in favour of 2):
> > >
> > > + Less confusing and less work to have two APIs for the same thing (we
> > > have to communicate this, document it etc.)
> > > + Gelly is actively maintained and getting a lot of contributions
> > > - Spargel users will have to move to Gelly at some point in time (I
> think
> > > this will happen anyways and it should be straight forward)
> > >
> > > The Spargel internal code will probably stick around as part of Gelly.
> > The
> > > question is whether we want to have two public APIs for this.
> > >
> > > – Ufuk
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message