We've never participated in GSOC before so I don't have a ton of experience to share. I can only speak from just general mentoring experience I've had and offer that I think the key to having success with this sort of thing is to be smart about the project options, to define them reasonably well, prefer items that are green fields of development and to not choose items from the critical path. I think your ideas are all potentially good ones in that spirit, though 5 and 6 I think root around too much in the guts of TinkerPop and 8 is a bit tricky because we'd need to coordinate with a party outside of TinkerPop. That coordination may not be hard though and in some ways i like this one the best of all your suggestions. I imagine we have plenty of time to coordinate with those third parties and get cracking on something (GSOC or not).
As for other ideas: 9. I think with gremlint making its way here and a new focus on Translators there are plenty of green fields there 10. a hero's parade is in store for the person who can use the infrastructure of 9 to generate our docs in every programming language 11. and for someone who prefers a quiet but legendary glory, coming up with a pure form of doc generation that simplifies process-docs.sh and getting us off of "sed to the awk to the grep to the pipe to the groovy" doc generation (no offense to kuppitz but he is not as available anymore to maintain that so it is a risky area for an important part of the code base) Anyway, I could probably think of other things, but I suppose we can have more discussion on what the specific possible projects might be. Insofar as firing up the GSOC process, I can't see any reason not to, especially since you're happy to take the lead on making it all happen. Thanks! On Thu, Nov 5, 2020 at 1:11 PM Divij Vaidya <[email protected]> wrote: > Hello all > > I was wondering if we want to participate in GSOC: > http://community.apache.org/gsoc.html > > I have a couple of ideas for an intern project and would be happy to mentor > a student. > > Some ideas are: > > 1. Replace WS and HTTP with HTTP/2. > 2. Integration with opentelemetry.io > 3. A UI tool to analyze query performance, query evaluation breakdown, > bottlenecks etc. > 4. Add universal tracing to TinkerPop, graph providers could extend from > it. > 5. Modify query execution to use a multi-threaded execution model > (current model is single threaded). > 6. Create extensible clients where vendors can provide custom step > implementation in a seamless manner. > 7. Add test suite to validate threading model on server. > 8. Write a go language client (or improve an existing one to the point > that it could be taken up as official driver) > > > Thoughts? > > Divij Vaidya >
