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
