Hello everybody, one of the great features of TinkerPop is that it is extensible. It is pretty easy for an implementation of TinkerPop Gremlin to add support for a regular expression predicate, for instance.
In addition, it is also possible to add custom data types based on the pluggable serialization system. However, unlike a custom predicate, support for custom data types requires changes both on the server side (i.e. within a particular implementation) as well as on the client side so that clients can read and make sense of such types when they are returned. This makes it fairly impractical for implementations to support custom data types. While it is easy to make the necessary changes on the server side, a particular implementation would have to extend each and every driver of the TinkerPop ecosystem in order to have its data type supported across the board. The last part is what makes it impractical. On top of that, since TinkerPop doesn't prescribe what the data type must look like, implementations can differ in their approach making it impossible for drivers to support them even if they invested the additional effort. Hence, I would like to make the case for including a "Geo" and a "Time" data type. Both are very common in the database world, very well understood (i.e. in how they should be represented and what they mean) and likely to be supported by a non-trivial number of implementations. If TinkerPop defines what these datatypes should look like, all drivers can support them. Note, that I am only advocating to declare the data types - not the predicates or operations on the types. The latter part could be controversial and should be left to implementations of TinkerPop. TinkerPop should only dictate the structure of the datatype and how it is serialized (both for gryo as well as graphson) to make communication possible. For time, I suggest we follow the lead of Java's Instant which seems well thought out: https://docs.oracle.com/javase/8/docs/api/java/time/Instant.html For geo, I suggest we initially focus on 2D spherical coordinate (latitude, longitude) and the simple geometries of WKT which is widely supported in the database world: https://en.wikipedia.org/wiki/Well-known_text WDYT? Cheers, Matthias
