+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 <[email protected]> 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 < > > [email protected]> wrote: > > > > Thank you Chris, that clears most of my doubts. > > > > Regards, > > Vikrant > > From: Chris Rohr > > Sent: 1/10/2013 2:29 AM > > To: [email protected] > > 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 < > > [email protected]> 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 <[email protected]> > > 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*
