Hi Haohui, Thanks for the reply. I am not suggesting to change existing java code to python or saying that we can live without javascript. All I am suggesting is that we do need to use a server side web framework. Try implementing a very basic requirement: user sessions( a logged in user doesn't need to login again on every page) with existing stack and you will understand what I am trying to say.
P.S. On a side note, you can use python to interact with Hadoop, Hive, Pig, Oozie. Again, I am not suggesting to use python instead of java in existing components. On Sun, Jul 13, 2014 at 11:40 PM, Haohui Mai <h...@hortonworks.com> wrote: > Thanks for your interests in contributing in Falcon. I am one of the > early contributors in Falcon UI, here are my two cents: > > Falcon has a browser-server architecture which needs to address two > requirements: > > 1. Provide a feature-rich UI (e.g. FALCON-290) to the browser. > > 2. The server-side logics have to integrate with existing Hadoop > ecosystems (e.g., MapReduce, Hive, Pig, and Oozie) which are heavily > based on Java. > > While personally I'm pretty open to any other technologies, but I am > yet to be convinced that how Python+Django will add any values to > address the above requirements. More concretely: > > i. JavaScript is (and will continue to be) an essential part of the UI > to meet requirement (1). The python stack cannot replace the > JavaScript part on the client side. > > ii. Falcon has to rely on Java to interact with other projects in the > Hadoop ecosystems, as there are few bindings in other languages for > these projects. > > > Using Python+Django might help attract attentions from the python > community, but I think that from the Falcon points of view, it is much > more important to keep align with the whole Hadoop ecosystems (which are > the main audiences of the Falcon project). Moreover, I don't think that the > merits that you mentioned for server-side technologies have to be coupled > with Python+Django -- in fact, there are many more implementation of > enterprise > features like exporting to Excel in Java. > > In short, I think that the current choice of Java+REST+JavaScript is quite > reasonable. Though I'm pretty open to any other technologies, I'm yet to be > convinced that Python+Django can be a superior choice. > > > Thanks, > Haohui > > > On Sat, Jul 12, 2014 at 7:06 PM, Ajay Yadav <ajayn...@gmail.com> wrote: > > > Any comments? I am awaiting your decision to start working on this. > > > > > > On Fri, Jul 11, 2014 at 11:10 AM, Ajay Yadav <ajayn...@gmail.com> wrote: > > > > > Hi Venkatesh, > > > > > > Valid question and I am glad that you gave an opportunity to discuss > it. > > I > > > have no particular bias towards using django. I have worked with client > > > side templates(not dust.js but more popular alternatives like mustache, > > > handlebars etc.) and client side MV* frameworks like backbone.js, > > angularjs > > > etc. It is completely possible to use both together, most common case. > > > > > > *Note: *I looked at the existing code and saw that the current work in > > > dust.js is very less - around15-25 lines(only dust templates part not > > > html/css). So may I take the liberty of rephrasing your question > slightly > > > as below > > > > > > *Question*: Assuming we can choose only one to keep stack mix to > minimum > > > - shall we use pure client side framework(like dust.js) or pure server > > > side framework(like django)? > > > > > > *Answer*: > > > *TLDR Version:* > > > Server side components offer more flexibility and extensibility than a > > > pure client side framework. Using only client side stack will rule out > > use > > > of database for dashboards, talking to other services,plugins etc. by > > using > > > just dust.js. Things like hardcoding of rest server end points, > graceful > > > degradation, number of parallel connections available in browser will > > limit > > > pure client side stacks. In other cases it will put a stress on falcon > > REST > > > API to be modified just for the dashboard. Using python stack instead > of > > > javascript, will help in getting more support from community. > > > > > > *Long Version* > > > > > > - *Convenience vs. Possibility* - Server side components give us > > > flexibility and extensibility to build for any use case in future as > > well. > > > Any future feature is possible to be built without dust.js and > > bootstrap > > > but not other way around. Dust.js and bootstrap just make it easier > > to do > > > lot of things to enhance user experience. > > > - *Features* - Consider the login page of the dashboard. We will > need > > > a database to store users/ integrate with ldap. We will need to > > generate > > > new random passwords when users forget passwords. Same for features > > like > > > bookmarks, custom dashboards etc. A lot of features like this can't > > be done > > > if we are not using any server side component. > > > - *Sanity of REST API* - REST services of falcon are not only for > web > > > browser consumption. They can be used by command line clients etc. > as > > well. > > > As the use cases for dashboard will evolve, it will become more > > involved to > > > do things using js alone on client side and it will put lot of > stress > > on > > > modifying REST API to suit just the client. For example consider the > > use > > > case of allowing an administrator to edit a process from an HTML > > form. REST > > > API will return plain text/xml and it will be tedious and slow to > > parse > > > everything in javascript side and then recreate it. Sending a json > and > > > accepting json just to cater to web client will be problem for > > > - Another use case can be to be able to export the reports like SLAs > > > missed in last quarter, metrics in pdf/excel format and it will not > be > > > possible to do it on client side and in lack of a server side > > component it > > > will again put stress on REST API to be modified just for dashboard > > UI. > > > - *Best Practices* - With just dust.js and simple htmls being served > > > through a webserver, we will have to deal with naming urls with > .html > > > extensions, hardcoding the REST end points in each HTML etc. > > > - *Browser constraints* - We will have to deal with browser > > > constraints like number of parallel connections, cross site > requests, > > > javascript not being enabled etc. This will also restrict the > > development. > > > > > > > > > - *Community Support* - This is purely my impression and I might be > > > completely wrong here. I see that more python developers are > involved > > with > > > big data/data science/machine learning eco system than more > javascript > > > developers. Hence it will be easier to find more support for > > maintaining > > > and extending these components in community if we develop them in > > django > > > instead of dust.js. > > > > > > > > > > > > > > > On Fri, Jul 11, 2014 at 2:28 AM, Seetharam Venkatesh < > > > venkat...@innerzeal.com> wrote: > > > > > >> I think we are using bootstrap and dust templates. I'd want to see if > we > > >> need to introduce more technologies into the mix. Do we need Python > and > > >> Django? > > >> > > >> > > >> On Thu, Jul 10, 2014 at 6:08 PM, Ajay Yadav <ajayn...@gmail.com> > wrote: > > >> > > >> > Thanks Srikanth and Venkatesh. > > >> > > > >> > I had looked at the UI and the graph database related code and I > will > > >> reuse > > >> > existing code where ever available. I checked for compatibility of > > each > > >> of > > >> > the software being used and they are all compatible with APL 2.0 > > >> (Python, > > >> > Django & Bootstrap). > > >> > > > >> > If you can assign the task to me on JIRA also, it will be > > >> > great(user:ajayyadava) Also, I got the balsamiq account for > > >> falcon(thanks > > >> > Srikant) and I will be asking all my questions on mocks there. > > >> > > > >> > > > >> > > > >> > > > >> > On Thu, Jul 10, 2014 at 2:45 PM, Seetharam Venkatesh < > > >> > venkat...@innerzeal.com> wrote: > > >> > > > >> > > Welcome aboard Ajay. Please let us know how we can help you to get > > up > > >> and > > >> > > running on this. The REST APIs are documented at: > > >> > > http://falcon.incubator.apache.org/docs/restapi/ResourceList.html > > >> > > > > >> > > Thanks! > > >> > > > > >> > > > > >> > > On Thu, Jul 10, 2014 at 7:12 AM, Ajay Yadav <ajayn...@gmail.com> > > >> wrote: > > >> > > > > >> > > > Hi, > > >> > > > > > >> > > > I would like to volunteer for > > >> > > > https://issues.apache.org/jira/browse/FALCON-37 > > >> > > > > > >> > > > I have more than 7 years of experience in building websites. I > > have > > >> > > > experience in both client side > > >> technologies(javascript/HTML5/Bootstrap > > >> > > > etc.) and server side technologies(Python/Django). > > >> > > > > > >> > > > I will need some help with iterating on the mocks as they don't > > >> seem to > > >> > > be > > >> > > > complete. I spent couple of hours on building a couple of pages > > >> using > > >> > > > "dummy" data to get an idea of what all APIs are required. > Please > > >> find > > >> > > them > > >> > > > attached. They are just a quick and dirty prototype and UI is > > pretty > > >> > raw > > >> > > as > > >> > > > of now, to get quick feedback. I used Django,HTML5 & Bootstrap. > > >> > > > > > >> > > > Please let me know if I can own this task. > > >> > > > > > >> > > > > > >> > > > > >> > > > > >> > > -- > > >> > > Regards, > > >> > > Venkatesh > > >> > > > > >> > > “Perfection (in design) is achieved not when there is nothing more > > to > > >> > add, > > >> > > but rather when there is nothing more to take away.” > > >> > > - Antoine de Saint-Exupéry > > >> > > > > >> > > > >> > > >> > > >> > > >> -- > > >> Regards, > > >> Venkatesh > > >> > > >> “Perfection (in design) is achieved not when there is nothing more to > > add, > > >> but rather when there is nothing more to take away.” > > >> - Antoine de Saint-Exupéry > > >> > > > > > > > > > > -- > CONFIDENTIALITY NOTICE > NOTICE: This message is intended for the use of the individual or entity to > which it is addressed and may contain information that is confidential, > privileged and exempt from disclosure under applicable law. If the reader > of this message is not the intended recipient, you are hereby notified that > any printing, copying, dissemination, distribution, disclosure or > forwarding of this communication is strictly prohibited. If you have > received this communication in error, please contact the sender immediately > and delete it from your system. Thank You. >
