Thanks, Alan, I'll do that. On Mon, Feb 21, 2011 at 7:44 AM, Alan Chaney <a...@mechnicality.com> wrote:
> Hi Nate/(Robert?) > > Very interesting project. > > > On 2/20/2011 4:39 PM, Robert Lockwood wrote: > > This project is to provide a web page GUI to control sensors that connect > to other (PC104) computers. The whole system, everything, will be on a > "LAN" on our research aircraft and will not connect to the web. I know that > this is a bit unusual. This provides a "universal" GUI that is not required > to be displayed only on our clunky FAA certified flat screen display (the > display is OK but the "mouse" and keyboard are difficult to use). > > Hmm - just to clarify - you want to be able to display on devices other > than the FAA screen. Do you have complete control over what device upon > which your GUI is being displayed? My reason for asking is that there's a > lot of overhead involved in learning about/developing/installing a web > server and web client applications and your use case is so far from how such > applications are normally used that it might be worth considering > alternatives. For example, you could write an RIAA application in Java/Swing > which would reverse the normal server/client approach. Your main application > could be the "client" and you could generate requests from the RIAA app. You > could use standard java networking (which is much simpler than messing about > with browser serialization) and implement a text book threaded pooling loop > in less than 100 lines of code. > > You could actually use other display toolkits - for example, GTK or > WxWidgets if you'd prefer to write in C++. Or you could stick with Java and > use an applet - still a perfectly viable technology and one that works well > when you are not trying to interface to every possible version and brand of > web browser. > > These solutions may be a better fit for your application than GWT. As this > is the GWT list, if you wish to pursue this line of discussion its probably > best to contact me off list. > > HTH > > Regards > > Alan > > > The main program with will be running at the same time as whatever server > we install on the same machine and will take care of servicing the other two > or three PC104s each of which will control one or two sensors, mostly > imaging radiometers. > > The web page will have buttons for the user, some kind of status log, a > canvas, and probably popups to enable entry of text or numbers. I expect it > to be rather simple as it is only an interface to the controller application > providing commands to the controller and receiving status messages. Commands > allow the user to turn cameras on and off etc. and to monitor operation. > After initialization of everything there won't be much activity. > > I expect that the headless PC104s that control the sensors will boot and > initialize without user input and then wait to connect to the master > controller. > > Thanks for your reply. > > > > On Sun, Feb 20, 2011 at 3:07 PM, Alan Chaney <a...@mechnicality.com>wrote: > >> Nate, >> >> See comments below: >> >> >> On 2/20/2011 11:02 AM, Nate wrote: >> >>> I just started with GWT and Eclipse and am new to Java as well - but >>> learning. >>> I'm trying to code some proof of concept apps for our larger project. >>> My model is that the GWT will start about at the same time that my >>> main application starts. >>> >> A GWT application is a way of creating a Javascript web page intended for >> AJAX operation - it "starts" when you enter a URL in a browser and the page >> is fetched from the server (or reloaded from a local cached version). >> Specifically speaking, your code execution is triggered by the browser >> onload event for the body tag. >> >> >> The user will establish a connection at some >>> point. Only one user will connect at any time. >>> >> To what? You mean only one client will connect to your server app. at one >> time? Thats a very unusual setup for a web server. Also, see above - the >> 'user' will establish a connection by opening the URL. >> >> >> The main application will enqueue status messages for delivery to the >>> server side when requested where they will be enqueued until requested >>> by the client. >>> >> Its not clear to me what you mean by "main application" - is this your >> business layer? Normally, you run web apps inside a servlet container, which >> responds to HTTP requests from the client (which may or may not be XHR) and >> then transfers a result page/data, which may be HTML, XML, JSON or binary >> depending upon the request type. Typically these apps have two or three >> layers - search google for "web application architecture" >> >> >> I had thought to use a timer to send the requests but >>> now see that it is possible to for the server to push the data >>> (Strings). >>> >> If you mean real server push to the client, that requires something like >> WebSockets (not widely supported, yet) or Comet (not supported on all >> servers). These generally require 'long running' TCP requests (similar to >> XMPP). >> >> See: >> http://en.wikipedia.org/wiki/Comet_%28programming%29 >> >> http://code.google.com/p/rocket-gwt/wiki/Comet >> >> >> http://www.google.com/events/io/2010/sessions/building-real-time-apps-app-engine-feed-api.html >> >> http://en.wikipedia.org/wiki/WebSockets >> >> http://code.google.com/p/gwt-websockets/ >> >> >> Also, you might like to look at the XMPP libraries (gwt-strophe and emite) >> - I realize that you may not be intending to build a chat app but XMPP also >> uses the 'long-running' model and you may get some tips and hints from >> looking at that stuff. >> >> >> >> I think I understand how to use the timer method and have coded a test >>> case. >>> >> Ok - typically the client app can poll the server - one important issue >> is the frequency of the poll requests which should be long enough to allow >> the client to retrieve the data and display it to the user. There are four >> steps: >> >> 1. transit of request from client to server >> 2. server-side processing of request and creation of response >> 3. transit of response to client >> 4. display of data to client. >> >> 1 and 3 depend upon your uplink and downlink bandwidths >> 2 depends upon the server performance and processing required >> 4 depends upon the way in which you display the results >> >> >> I think that I would prefer to have the server push the data (after >>> some initialization it shouldn't be frequent) but don't understand the >>> trade offs except that it appears that using a timer is easy but the >>> push code is much more complex. >>> >> Yep. I suggest that you get a polling version to work first and then >> consider whether a 'push' version is more appropriate for your use case. >> >> Question: Does the push model add much overhead in terms of CPU >>> utilization or critical resources? If not I'll start to examine >>> demonstration code that I found. I would appreciate any advice. >>> >>> See the attached links. It looks to me like most of the possible GWT >> libraries are still at a comparatively early stage - I suggest that until >> you are really familiar with all the technologies its a good idea to start >> with the simplest approach (polling), get that to work, and then consider >> some kind of 'push' technology. >> >> HTH >> >> Alan >> >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Google Web Toolkit" group. >> To post to this group, send email to google-web-toolkit@googlegroups.com. >> To unsubscribe from this group, send email to >> google-web-toolkit+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/google-web-toolkit?hl=en. >> >> > > > -- > When I was 12 I thought I would live forever. > So far, so good. > > -- > You received this message because you are subscribed to the Google Groups > "Google Web Toolkit" group. > To post to this group, send email to google-web-toolkit@googlegroups.com. > To unsubscribe from this group, send email to > google-web-toolkit+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/google-web-toolkit?hl=en. > > > -- > You received this message because you are subscribed to the Google Groups > "Google Web Toolkit" group. > To post to this group, send email to google-web-toolkit@googlegroups.com. > To unsubscribe from this group, send email to > google-web-toolkit+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/google-web-toolkit?hl=en. > -- When I was 12 I thought I would live forever. So far, so good. -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
