incubator-blur-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vikrant Navalgund <vikrant.navalg...@gmail.com>
Subject Re: Blur Console v2 Design Proposal
Date Thu, 03 Oct 2013 00:10:53 GMT
+1 For proxying Blur API calls via a Jetty server and relaying back the
data to the Client(Browser). With this approach we will have a clean
separation of the Client and the Blur API.

Please let me know how to begin with the tasks.

Regards,
Vikrant


On Thu, Oct 3, 2013 at 1:26 AM, Chris Rohr <rohr.chris@gmail.com> wrote:

> So as I have been getting into this more I am finding that using the
> JavaScript API from the browser is not a good idea.  1. We will have to
> deal with cross site scripting issues. 2. It will require the ENTIRE Blur
> API to be exposed to browsers (potential security problem).  I think we
> should just create calls in the Jetty Server that will make the calls to
> Blur and return what is needed for the console.
>
> I want to get one call built into my branch then I will push it up so I can
> get help. (Hopefully today)
>
> Thanks,
> Chris
>
> On Tuesday, October 1, 2013, Chris Rohr wrote:
>
> > All,
> >
> > One thing I have found in looking at using the Javascript API is that we
> > will need to make sure that the Blur Thrift server supports CORS
> > (Cross-Origin Resource Sharing), this basically will allow us to get
> around
> > the Same-Domain policy since most of our browsers will not be on the Blur
> > box itself.  Do any of you know if the server is setup with that turned
> on?
> >
> > Thanks,
> > Chris
> >
> >
> > On Mon, Sep 30, 2013 at 8:38 PM, Vikrant Navalgund <
> > vikrant.navalgund@gmail.com> wrote:
> >
> > Thank you Chris, that clears most of my doubts.
> >
> > Regards,
> > Vikrant
> > From: Chris Rohr
> > Sent: 1/10/2013 2:29 AM
> > To: blur-dev@incubator.apache.org
> > Subject: Re: Blur Console v2 Design Proposal
> > Vikrant,
> >
> > Thank you for your thoughts.  I will try to answer your questions here:
> >
> >    >>> What is this serving up? Is this a web service which would be
> > consumed by the AngularJS front end. Since you mentioned that it would
> be a
> > Jetty server(HTTP server + servlet container) a little clarification
> would
> > be great.
> >
> > In my initial thoughts, all the Jetty server would be used for is to
> > provide an HTTP server and serve up the static html pages.  All of the
> > dynamic nature of the console would be done through Javascript using
> > AngluarJS and the JS Blur API.  However, in the future if there is a need
> > for functionality that can't be done from the Browser directly (i.e. User
> > logins, zookeeper status, etc) then we could setup some basic JSON web
> > service calls that would be served up by Jetty.
> >
> >    >>> Are we going to pull the information from within the
> > Browser(something like AJAX) or the Jetty server would do a query to the
> > Thrift service and pass it back to the Browser.
> >
> > We will be trying to use the JS Blur API to access Blur directly,
> however,
> > we may run into Cross site scripting issues depending on how thrift works
> > in JS and if that is the case then we would need to build proxies through
> > the Jetty server.
> >
> >    >>> Since we will be using AngularJS and a Jetty server please clarify
> > about not relying on a front-end and back-end component.  A typical
> > scenario involving all the above 3 components would be helpful. This
> would
> > also help us in figuring out the options we have while selecting the
> > technology.
> >
> > Currently the console contains 2 pieces of software, a Ruby on Rails
> > application (front-end) and a Java application (back-end).  The Java
> > application handles all of the information collection in Blur (i.e.
> polling
> > for statues, and tables, and queries) and stores everything in a
> database.
> > The Ruby on Rails application presents all of the data in GUI form.  The
> > Ruby on Rails application does have some direct access to Blur, but does
> > not have direct communication to the Java application.  This proposal
> does
> > away with the 2 separate pieces of code to 1. help simplify the logic and
> > 2. help simply setup and startup of the console.
> >
> > I hope this answers your questions, please let me know if you think of
> any
> > more.
> >
> > Chris
> >
> >
> > On Mon, Sep 30, 2013 at 2:38 AM, Vikrant Navalgund <
> > vikrant.navalgund@gmail.com> wrote:
> >
> > > Hello Chris,
> > > Thanks for the writeup.
> > > As a developer interested in contributing to the new BLUR console I
> have
> > a
> > > few questions.
> > > Please ignore my lack of understanding of the architecture.
> > > Treat me as a newbie to BLUR. My questions are inline.
> > >
> > >
> > > On Mon, Sep 30, 2013 at 10:33 AM, Chris Rohr <rohr.chris@gmail.com>
> > wrote:
> > >
> > > > All,
> > > >
> > > > As I have begun to start the next version of the console I wanted to
> > give
> > > > everyone my proposal for what should be in it and get any feedback
> that
> > > you
> > > > may have.  I have created a new branch (new-blur-console) and will be
> > > > pushing it up as soon as I can.  Please let me know if you have any
> > > > questions/opinions/suggestions about this proposal.  If I don't hear
> > from
> > > > anyone, I will just assume it looks good and I will move forward.
> > > >
> > > > Thanks in advance,
> > > > Chris
> > > >
> > > > *Blur Console v2 Design Proposal*
> > > >
> > > > *Purpose*
> > > >
> > > > This writeup will help to determine what direction the console
> portion
> > of
> > > > Blur should go.  There has always been a need for a push button, easy
> > > setup
> > > > solution so that dev-ops could get up and running with the console
> > > faster.
> > > > *NOTE: *This is purely a suggestion and all opinions and
> > recommendations
> > > > are welcome.
> > > >
> > > >
> > > > *Server*<
> >
> >
>



-- 
*Regards*,
*Vikrant Navalgund*

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message