Hey Stephen, Starting from the end of your mail - yes. Proposal of this change is side effect of middle step between level 1 and 2 support. I am able to generate metadata, however it forces to install all the core dependencies upfront, even if they are not used at runtime.
I proposed to devide io package into format specific modules cause Io interface is doing too much. From one hand it does allow to read graphson and graphml and gyro at the same time which is breaking single responsibility pattern leading to multiple reasons to modify it. More over Io interface with default methods is embedded in Graph itself so if any change will be made to GyroMapper initialization interface will be affected and bytecode change as well. Having a references in Graph.Io interface to default providers is causing bidirectional dependency between packages. I do understand that you want to support given three formats of storages. Keeping it in project bounds is one thing, but making them holly cows sitting inside structure package palace is another. You did mention that you would like to make vendor customizations to be plugged into Gyro or Graphson which is yet another reverse thought. In case of need they can rely on customization of mapper out of the box and it have nothing to do with having given format part of structure package dependencies. SPI interfaces are made to make vendor implementation easier, not harder. Ie. maybe for some reason one of vendors will decide to use compressed bson instead of plain json and then all the calls from gremlin core dependant on graphson will be broken. Huge effort will be pushed to provider for supporting format which is not his point of interest while he still may use Jackson for writing bson. Kind regards, Lukasz > Wiadomość napisana przez Stephen Mallette <[email protected]> w dniu 25 > mar 2015, o godz. 13:38: > > I don't think we want to have separate modules for individual elements of > IO. We purposely chose to have them in gremlin-core as they represent > integral parts of database operations we wish to expose. Each of the three > GraphReader/Writer implementations serve specific use cases with respect to > input and output formats. These uses cases are detailed in the > documentation: > > http://www.tinkerpop.com/docs/3.0.0-SNAPSHOT/#_gremlin_i_o > > Given that these three implementations cover all the IO use cases we've > encountered over the years, we don't expect to have any others. We would > hope that third-party maintained implementations from the community pop-up > (i.e. GML, gefx, tulip, etc.), but those are not implementations we wish to > include/maintain in our code base. As such, tight coupling in the > structure package doesn't worry me so much - in fact it does hold some > necessity for vendor implementations of the Graph interface where custom > serializers need to be plugged directly into Gryo and GraphSON and as such > having all of that packaged directly in gremlin-core is advantageous. > > Did this proposed change have anything to do with your thoughts on how to > OSGi-enable TinkerPop? > > > On Tue, Mar 24, 2015 at 6:34 PM, Łukasz Dywicki <[email protected]> wrote: > >> Dear all, >> After my yesterday mail I made an attempt to devide graphson and gryo >> packages from gremlin core into their own modules. Then I have found that >> Graph.Io interface (and DefaultIo) allows to create multiple >> implementations of graph readers and writers at the same time. >> This introduces tight coupling between structure package containing mainly >> interfaces and IO implementations. What I was thinking about was to make Io >> interface a single purpose with generic methods allowing to read/write >> graph from file or input stream - this would lead us to GraphsonIO, GryoIO >> and GraphmlIO. Question - if there are any implications for API on such >> change except changes in code calls? >> >> Best regards, >> Lukasz
