[
https://issues.apache.org/jira/browse/DRILL-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13643791#comment-13643791
]
Jacques Nadeau commented on DRILL-58:
-------------------------------------
My quick opinions on this:
>From experience, I want to avoid adding lots of interfaces directly to the
>Drillbit. For applications other than other Drillbits, I'd like to constrain
>that all to the UserAPI/RPC interface. The only other interface that I see
>being available is JMX for metrics. As such, my preference would be that what
>other non-query information that the web gui need be also sent through the
>Drillbit API. I think this will keep things simple and always ensure that
>cross version and cross language compatibility are managed. This also means
>that later managing the implementation of security is much simpler. Given
>that, if you need more functionality from the Drillbit it would be best to add
>additional request/response types and message types to the User API.
As far as server infrastructures go, I've actually really liked some projects
I've worked on recently where the server component only exposes a REST JSON API
and static asset serving. I've used both Jersey and Resteasy in that way with
much success. If someone wanted to do something else, I've actually found
JSF+Primefaces reasonably competent albeit irritating and not very rest
friendly (and slow/big).
My other thought would be that if we want to have a server component, that we
try to stick to servlet APIs for the functionality. Easy starting of Jetty is
great if you don't already have infrastructure in place. However,
productionizing many separate Jetty instances can be a real pain, especially if
you have another web container that you utilize (like Weblogic or Glassfish).
Since our requirements should be pretty sparse, it would be great if we didn't
force people to use one container. (To me this just means that we separate out
the WAR application from the running of it within embedded jetty or tomcat.)
One other question here is whether the server component should even be in Java.
I know a lot of people like Python & Django for these types of applications
and if we commit to constraining interaction to the protobuf user api, the
person that will actually spend a lot of time writing this component should
feel comfortable using what makes the most sense given the requirements.
> Create a WEB UI war that can be deployed along with Drillbits
> -------------------------------------------------------------
>
> Key: DRILL-58
> URL: https://issues.apache.org/jira/browse/DRILL-58
> Project: Apache Drill
> Issue Type: Improvement
> Reporter: David Alves
> Assignee: Michael Hausenblas
>
> A while ago Michael created a simple web UI to submit queries to Drill.
> It'd be nice if we could package it in war for and deploy it in Drillbits
> through jetty.
> Hive web ui (the way it's deployed) might be a good starting point.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
