Thanks all for the responses. I'm still thinking this through, will follow up when we make a decision. The analysis library is in development in C++, though we could probably port to another language if there were a compelling reason.
One option I am going to explore more is Native Client: http://code.google.com/p/nativeclient-sdk/ (I'd never heard of this 'til I started googling yesterday.) I'd have no problem telling users that they have to use Google Chrome for the local version. Alain, can you run standard java code in an Air app? I thought it had to be Flex/ActionScript. On Sat, Dec 4, 2010 at 11:06 AM, Evan Ruff <[email protected]> wrote: > Alain, > > That's sweet. I've been kicking around HTML5 Offline stuff and haven't > really had a lot of success as of yet. This looks like a great low- > impact interm solution until the pure stuff is ready! > > E > > On Dec 3, 6:00 pm, nino ekambi <[email protected]> wrote: > > Hello you Adobe AIR will perfectly fit your need. you can use adobe AIR > with > > GWT without any use of JavaScript using the library here : > http://code.google.com/p/gwt4air/ > > > > <http://code.google.com/p/gwt4air/>for any help feel free to contact me > > > > Regards, > > > > Alain > > > > 2010/12/3 Brian Reilly <[email protected]> > > > > > > > > > > > > > > > > > As much as I like GWT, I think it might not be the right tool for your > > > situation. > > > > > Your two use cases are: > > > > > * Remote data and compute > > > * Local data and compute (unless you meant that desktop use would use > > > remote compute, but I don't think so because that would require > transmitting > > > local data to the server) > > > > > While being able to reuse the UI (for both consistency and > > > development efficiency) is a good goal, it sounds like your real > substance > > > is the analysis algorithms. What language are those implemented in? > > > > > Assuming you're using Java, you do have some options. A separate > desktop > > > application is one of them. You could also go with a webapp and use > > > something like Jetty on the desktop, like Gaurav suggested. I think > that > > > would be awkward in desktop mode as you'd have two processes to worry > about, > > > the jetty server and the browser, which may be tricky to do well and > may be > > > confusing to users. Plus your access to the local filesystem is going > to be > > > awkward. You'd probably have to present an upload widget to invoke the > > > system file dialog, but then just pass the file path to the locally > running > > > server for it to open directly (which hopefully it would be able to > do...) > > > > > You might instead want to look into using Swing, SWT, JavaFX, or Apache > > > Pivot. I went to a NEJUG talk about Pivot earlier this year and was > pretty > > > impressed with it. Some things even reminded me of GWT. > > > > > One catch, though... I'm not sure if it's just their demos, but they > > > require Java 6, and they don't quite work in-browser on Mac OS X 10.5. > > > Supposedly they do work in 10.6, but I haven't upgraded yet so I can't > > > confirm. (See > > > > http://mail-archives.apache.org/mod_mbox/pivot-user/201006.mbox/%3C8D8726BA- > [email protected]%3efor the response to my question on > the Pivot mailing list.) > > > > > -Brian > > > > > On Fri, Dec 3, 2010 at 1:36 PM, Gaurav Vaish <[email protected] > >wrote: > > > > >> Why not use Jetty (Embeddable, Lightweight Java Servlet Container - > > >> cross platform). > > > > >> -- > > >> Happy Hacking, > > >> Gaurav Vaish > > >>http://www.mastergaurav.com > > > > >> On Dec 3, 10:09 pm, Brett Thomas <[email protected]> wrote: > > >> > Hi all, sort of an off beat question: what's the best cross-platform > > >> library > > >> > for a local web server, that could effectively make a standard GWT > app > > >> into > > >> > a desktop app? Ideal would be super light weight, and just allow > users > > >> to > > >> > run the app offline, with local data. Language could be Java, C++ or > > >> Python. > > > > >> > If curious about why such a library would be desired, some > background at > > >> the > > >> > end of the email... > > >> > Thanks for the help, > > >> > Brett > > > > >> > *** > > >> > Background: > > > > >> > I'm about to build an app for researchers to browse and analyze > large > > >> > scientific datasets. We want to permit two uses: > > >> > -- Web version: users can browse/analyze common public datasets over > the > > >> web > > >> > -- Local version: users can do the same browsing/analysis on their > own > > >> data > > >> > set, *without* transferring the data to the server. > > > > >> > The plan now is to build a desktop app for this. I'd love to make it > a > > >> > browser app instead, with GWT as the front end. If we went this > route, > > >> we'd > > >> > have to provide some software download for the local version. Here > are > > >> the > > >> > options I can think of: > > >> > 1 -- Local version is a completely separate app. Hope to avoid this > so > > >> users > > >> > get the same interface on web/local. > > >> > 2 -- Use Gears (or Adobe Air). Avoided because that would require > > >> > transferring server side analysis code to javascript (or > Actionscript). > > >> > (Right?) > > >> > 3 -- Ship an executable that starts a local web server. User views > app > > >> athttp://localhost:12345/inthe browser. > > >> > (Any others I'm missing?) > > > > >> > I am trying to assess the feasability of #3. The ideal workflow of > our > > >> app > > >> > would be: > > >> > -- Researcher checks out our site in the browser and tries it out. > Likes > > >> it, > > >> > clicks the "Try this on your own data" button > > >> > -- Downloads executable with mystery web server described above :) > > >> > -- Double clicks executable and a minor GUI shows up with a "Get > > >> started!" > > >> > button > > >> > -- User clicks, and the app is loaded in the browser > > >> athttp://localhost:[whatever > > >> > port]/. The app looks the same as it did online with the same > > >> functionality, > > >> > except the "Select data set" option lists local files... > > > > >> -- > > >> You received this message because you are subscribed to the Google > Groups > > >> "Google Web Toolkit" group. > > >> To post to this group, send email to > [email protected]. > > >> To unsubscribe from this group, send email to > > >> [email protected]<google-web-toolkit%[email protected]><google-web-toolkit%2Bunsubs > [email protected]> > > >> . > > >> 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 > [email protected]. > > > To unsubscribe from this group, send email to > > > [email protected]<google-web-toolkit%[email protected]><google-web-toolkit%2Bunsubs > [email protected]> > > > . > > > 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 [email protected]. > To unsubscribe from this group, send email to > [email protected]<google-web-toolkit%[email protected]> > . > 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
