In general if people see a need for an extensible TinkerGraph and want to avoid making forks it seems a reasonable ask. My only slight concern might be that we lose the strong likelihood that when a user says something like "my query fails on Graph DB XYZ but works on unmodified TinkerGraph" that there is an issue with the other implementation has or at least some conscious deviation from the "reference implementation". So we will have to get used to asking "have you applied any extensions?". Other than that, if people have good use cases for wanting to extend TinkerGraph I can't think of other reasons right now to say it is a bad idea.
Would the extension mechanism you envisage allow for graph providers to customize TinkerGraph to better mirror their implementation's behavior - without needing to fork it? In one case I can think of, perhaps a provider does not support all Gremlin steps yet for some reason but wants to enable easy development and testing using TinkerGraph for their users. Or would you perhaps see that as violating the API contract that final was used to protect? On 2020/09/10 11:33:07, Stephen Mallette <[email protected]> wrote:
Should TinkerGraph be extendable? This is not a new discussion. Most> notably, Michael Pollmeier long ago wanted to allow for this to> experiment with a TinkerGraph fork where he used schemas to drastically> increase the performance:> https://github.com/ShiftLeftSecurity/tinkergraph-gremlin> which then was replaced by the quite neat:> https://github.com/ShiftLeftSecurity/overflowdb> To the best of my knowledge, the argument against making TinkerGraph> extendable has been that allowing extension of TinkerGraph would create> situations where we felt we couldn't alter TinkerGraph APIs and behaviors> as easily as we would like and wanted to maintain the flexibility to change> what we wanted when we wanted without fear of breaking those extending it.> Since those early discussions to come to that reasoning many years ago,> I've learned that TinkerGraph has a lot of interesting usages that you> normally wouldn't think of. I've seen/heard it used internally within graph> systems quite regularly. This might be for testing or functional purposes> and there are times when being able to extend it would be quite handy where> a fork of TinkerGraph would be too heavy handed. I've also come to the> realization that in our current times, TinkerGraph is quite stable in terms> of API and behavior (the two things we've wanted to protect with "final"> modifiers). There are few changes, the last major one probably relates to> the introduction of null support in 3.5.0 almost 12 months ago.> Given these realizations and another recent request to "remove a final" in> TinkerGraph, I've started to wonder if the reasons we had many years ago> still hold and am inclined to think that they do not. Does anyone have> thoughts on the matter?> As an aside, it's interesting that when a project lives long enough, the> decisions that felt like absolutes begin to feel a bit more mutable. For> example, for years we thought we'd never maintain Gremlin in other> languages in our repository, but now we hold many languages here and GLVs> are highly popular in what they allow. Sorta thought provoking....>
Cheers, Kelvin
