You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tinkerpop.apache.org by Stephen Mallette <sp...@gmail.com> on 2016/08/09 18:02:41 UTC

[DISCUSS] Deprecating registry() on Io.Builder

This is really low-level IO stuff so unless you are a Graph Provider you
can probably largely ignore this. If you were following along on JIRA you
probably already know what this post is about:

https://issues.apache.org/jira/browse/TINKERPOP-1402

Basically, there is no way for a Graph implementation to specify a
ClassResolver to a GryoMapper. Up until now, we've relied on the user to
make that specification themselves.

Why did that happen? Well, ClassResolver came along after the IoRegistry
work as an added customization to IO that providers could tack in.
ClassResolver is a feature specific to Kryo and not so easily generalized
to other IO packages that we have. It's not a terribly well known feature
and you really need to know what you're doing when you write one, but
basically it allows for some very fine grained control of how Kryo does its
work.  Of course, when you have one it would be much nicer if the Graph
just handled that configuration for you and then the user wouldn't have to
worry about it.

In some discussion with Bryn on that ticket, we think our best approach is
to just deprecate Io.Builder.registry() and include a new method called:

public Builder<? extends Io> onMapper(final Consumer<Mapper.Builder>
mapper);

With that method a Graph provider could do whatever they liked to the
Mapper.Builder which would include adding an IoRegistry, adding a
ClassResolver, etc.

Since we are just deprecating, this would be a non-breaking change. I think
we would only look to make this change in master for the 3.2.x line of
code.

If there are no objections in the next 72 hours (Friday, August 12, 2016,
2:00pm EST), I'll assume lazy consensus and press forward with implementing
that change.

Thanks,

Stephen