Glad i came across this discussion because i've oppened a ticket to add Geode OQL Interpreter for Zeppelin: https://issues.apache.org/jira/browse/ZEPPELIN-189
I'm working on PostgreSQL/HAWQ/GPDB Interpreter [ZEPPELIN-70] and i have been exploring a Geode Interpreter support as well. Any ideas for non-OQL Interpreters use cases/support? Cheers, Christian On 28 July 2015 at 14:04, Eric Pederson <[email protected]> wrote: > Hi William - on the Zeppelin thing, do you mean a OQL runner/visualizer a > la Databrowser? That would be cool. > > > -- Eric > > On Tue, Jul 28, 2015 at 1:08 AM, William Markito <[email protected]> > wrote: > > > Hello João, > > > > Let me try to shed some light here... > > > > On Mon, Jul 27, 2015 at 8:42 PM, João Peixoto <[email protected]> > > wrote: > > > > > Dear Geode devs, > > > > > > I've been following (and to some extent participating) the mailing > lists > > > and I find the project really interesting. > > > > > > > And we're happy with that! :) > > > > > > > > > > I would like to contribute but I feel a little lost. I know that there > > is A > > > LOT going on right now with the donation to Apache and all. > > > > > > I've been looking into a couple issues that I could tackle to begin > with: > > > * https://issues.apache.org/jira/browse/GEODE-36 : Changing the shell > to > > > "geode". Seems like an easy enough task, since you seem to use Spring > > > Shell. After looking at the code it is not that simple. You use Spring > > > Shell 1.0.0 and JLine (older version). Spring Shell 1.1.0 is not > > compatible > > > and would require a lot of changes, but I'm not sure of the current > > > implementation decisions nor who to ask about it. > > > > > > > I'd hold a little bit on the rename to Geode for now but the > upgrade/update > > to new version of the Spring shell would be an awesome contribution, but > > not sure if that's the easiest way to start... > > > > > > > > > * https://issues.apache.org/jira/browse/GEODE-34 : Experimenting with > > > Reactor/Reactive Streams. Much more "researchy" and for all intents and > > > purposes, "hardcore". Specially not knowing the internal structure > (apart > > > from studying the code) nor who to ask about it, like an overview. > > > Definitely sounds fun though. > > > > > > > Also agree. > > > > > > > > > > On this subject I'd like to ask your advice. Should I wait for Geode to > > be > > > out of incubating status before diving into the project itself? is > there > > > some sort of implementation decisions notebook or general internal > > > architecture diagram/document? Or should I just power through it? > > > > > > > > *Not at all!* In fact getting contributions while we're incubating are > very > > important and a key metric towards our graduation. > > > > So first of all, at the How to contribute > > <https://cwiki.apache.org/confluence/display/GEODE/How+to+Contribute> > page > > we listed a few ideas that would be interesting and some are actually > > fairly simple ways to contribute without that much knowledge of Geode > > internals. But other ideas not listed there are also welcome! > > > > Giving some other examples: > > > > - Geode has an huge number of features and when we decided to open > > source GemFire we *left out* of the package the product examples on > > purpose, given that they would need to be updated and refactored. That > > work > > I've not started yet and would be tracked in GEODE-33 > > <https://issues.apache.org/jira/browse/GEODE-33>. > > - Currently I'm looking into Apache Mesos and Marathon integration or > at > > least a tutorial on how to run a Geode cluster on Mesos. We could > work > > together if you think that's interesting. GEODE-49 > > <https://issues.apache.org/jira/browse/GEODE-49> > > - Creating a Apache Zeppelin interpreter should also an interesting > > add-on to the project. > > - A WAN integration (integrating Geode clusters geographically > > separated) mechanism using Apache ActiveMQ or Apollo would be an > > interesting and yet challenging feature. Problems like keeping > systems > > in > > sync, taking care of consistency, etc.. > > - Provide a flag/setting on Geode that would enable exposing JMX over > > REST through something like Jolokia, considering security, etc... > > - Provide extra functionalities in GFSH adding functions or integrated > > security through OAUTH. > > - Enhance our backup/restore experience and procedures. Here for > > example one could leverage JClouds, Spring Cloud or some other "cloud" > > API > > and provide integration with AWS Glacier > > <http://aws.amazon.com/glacier/> (or > > Azure Backup) doing backup/restore on a cheap cloud storage service. > > > > Some of these ideas would actually require extra discussions here, given > > that I'm pretty much sharing my personal list of *interesting* stuff to > add > > to the project, but should probably be well accepted and other committers > > would pair or act as champions on the work helping you as possible/when > > needed. > > > > Examples, documentation and bugs also definitely important and valuable > > contributions as well. > > > > Regarding Geode internals and more details please check these links: > > > > - > > > > > https://cwiki.apache.org/confluence/display/GEODE/Geode+Internal+Architecture > > - > > > > > https://cwiki.apache.org/confluence/display/GEODE/Core+Distributed+System+Concepts > > - > > > > > https://cwiki.apache.org/confluence/display/GEODE/Source+code+launch+points > > > > Hope that helps. > > > > > > > Sorry for the long post. Thanks in advance > > > Joao > > > > > > > > > -- > > William Markito Oliveira > > Enterprise Architect > > -- For questions about Apache Geode, please write to > > *[email protected] > > <[email protected]>* > > > -- Christian Tzolov <http://www.linkedin.com/in/tzolov> | Solution Architect, EMEA Practice Team | Pivotal <http://pivotal.io/> [email protected]|+31610285517
