Hi,
I had started work on this feature about system communication, and make
some PoCs that I commit in the past at marvin-repl and basically the idea
is is to leverage existing engine resources using scala and python via gRPC
as stated in the previous email from yifei, but this is my initial idea! If
you like to discuss further about a better architecture and resources of
this feature, seems good to me too.
My basic idea consists in this basic diagram:
+-------------------+ +--------------------+
| Basic REPL | +---------> | Docker |
| Interface | <-gRPC-+ | Instantiation |
+-------------------+ +-------------------+
On Thu, Oct 18, 2018 at 3:00 PM Lucas Bonatto Miguel <lucasb...@apache.org>
wrote:
> + 1 for migrating the REPL repo to Apache
>
> 1) The REPL itself, it would be an application in which language? Remember
> that the main idea is to allow the user to program on his preferred
> language in the REPL.
>
> 2) Should the engine-generate command also generate a docker image with
> the user's application?
>
> 3) What type of communication would happen between the REPL and the engine
> via Docker SDK? Would the REPL pass snippets of code to be executed by the
> docker container?
>
> 4) Have you considered code completion in the REPL?
>
>
> On Thu, Oct 18, 2018 at 7:53 AM Zhang Yifei <yifei.z.l...@gmail.com>
> wrote:
>
> > Ok guys,
> >
> > The basic idea is to provide only one Toolbox for multiple languages.
> > We are looking for possibility to build a single Marvin Repl,
> > instead of severals toolboxes with differentes interfaces or commands.
> >
> > In this case, the engine-generate command will download and start a
> Docker
> > container with basic engine structure corresponding the choosed language.
> > this means we don't need to build Toolboxes of differents languages, we
> > just
> > build the engine template of all languages that we want to support and
> > provide it
> > as Docker containers
> >
> > We have started researches around our basic requirements like:
> > - Repl interface
> > - System communication
> > - Connection security
> > - Tool popularity
> > - Update complexity
> > - Languages support
> > - ......
> >
> > And we did some POC with code here:
> > https://github.com/marvin-ai/marvin-repl
> >
> > There is POC testing gRPC using Scala and Python,
> > Repl inteface and Docker SDK with NodeJS,
> > Repl interface and Docker SDK with Python.
> >
> > At this moment we prefer the Repl interface + Docker SDK way, because
> good
> > part of the requirements
> > will be guaranteed by Docker.
> >
> > With this informations, what do you think? Should we submit all this POCs
> > to Apache Repo?
> > Please feel free to opine.
> >
> >
> > Thats all, thanks!!!
> >
> >
> > Em ter, 16 de out de 2018 às 18:55, Daniel Takabayashi <
> > daniel.takabaya...@gmail.com> escreveu:
> >
> > > Zhang,
> > >
> > > I think the best approach is give us a better explanation about this
> new
> > > feature and how this can help us to archive the desired feature
> (support
> > > multiple languages). Than if the majority agree than I can do the
> merge,
> > > just like I did before, but in another branch.
> > >
> > > Let me know if makes sense, ok?
> > >
> > > Taka
> > >
> > > Em ter, 16 de out de 2018 às 14:00, Luciano Resende <
> > luckbr1...@gmail.com>
> > > escreveu:
> > >
> > > > So, what is the POC, is it a refactoring of the existing repo? Or is
> > > > it a new rewrite of the repo?
> > > >
> > > > Just asking as it might make sense to make it a branch then actually
> a
> > > > thing in parallel, as this will have an effect for releases, etc. but
> > > > you guys know more here than I do.
> > > >
> > > > Also, it's probably good to have a write up of the main direction of
> > > > the design that can help people get familiar with the new approach.
> > > > On Tue, Oct 16, 2018 at 11:12 AM Zhang Yifei <yifei.z.l...@gmail.com
> >
> > > > wrote:
> > > > >
> > > > > Hey guys,
> > > > >
> > > > > We have reorganized the Poc repo, and want to merge it to our
> Apache
> > > > repo.
> > > > > Just making sure here before we do the merge, because im not sure
> if
> > > > doing
> > > > > this will perserve the Git commit history.
> > > > > What we are planning to do is:
> > > > >
> > > > > git filter-branch --subdirectory-filter <git origin_repository
> > > directory>
> > > > > -- --all
> > > > > mkdir POCs/
> > > > > git mv * POCs/
> > > > > git commit -m "colleted the data to move"
> > > > >
> > > > > git clone <git destination_repository_url> cd <git
> > > > > destination_repository_directory> git remote add
> > > origin_repository_branch
> > > > > <git origin_repository directory> git pull origin_repository_branch
> > > > master
> > > > > --allow-unrelated-histories git remote rm origin_repository_branch
> > > > >
> > > > >
> > > > > Thanks in advance !
> > > > >
> > > > > --------------------------------------------------------------
> > > > > Zhang Yifei
> > > >
> > > >
> > > >
> > > > --
> > > > Luciano Resende
> > > > http://twitter.com/lresende1975
> > > > http://lresende.blogspot.com/
> > > >
> > >
> >
> >
> > --
> > --------------------------------------------------------------
> > Zhang Yifei
> >
>
--
*Alan Silva* | Solutions Architect
t. +55 (11) 99951- <0000000000>5242 e. alan.si...@cloudera.com
cloudera.com <http://www.cloudera.com>
[image: Cloudera] <http://www.cloudera.com/>
[image: Cloudera on Twitter] <https://twitter.com/cloudera> [image:
Cloudera on Facebook] <https://www.facebook.com/cloudera> [image: Cloudera
on LinkedIn] <https://www.linkedin.com/company/cloudera>
