Well, websockets will not work if your clients come from corporationsas they usually deploy proxies with disallowed HTTP CONNECT. But as many said this is not really Derby topic. Just my EUR 0.02.
On Fri, Feb 12, 2010 at 10:21 PM, Ronald Rudy <ronchal...@gmail.com> wrote: > As I understand it WebSocket is no longer part of the HTML5 spec, but its own > separate spec.. And only Chromium currently supports it (I think).. > > WebSockets would, however, be much more preferable if you have strong control > over the client browser(s).. but the polling - which is absolutely very brute > force and inelegant - will work in any browser from the last 4-5 years.. > > On Feb 12, 2010, at 4:01:54 PM, Erin Drummond wrote: > >> There IS a way to push data to the client, and I am using it >> successfully right now. >> >> It's called WebSocket and its part of HTML5, but only a few servers >> and browsers support it at the moment. Jetty 7 is one such server, and >> apparently later versions of WebKit and Gecko support it on the >> browser side (im not sure since my WebSocket client is a Java >> application which I wrote myself). >> >> Otherwise you can use Bayeux/Cometd to do long polling which simulates >> server push (its horridly complex compared to WebSockets depending on >> what you want to do with it, but it is much more widely supported) >> >> Erin >> >> On Sat, Feb 13, 2010 at 8:49 AM, Kristian Waagan >> <kristian.waa...@sun.com> wrote: >>> Ronald Rudy wrote: >>>> >>>> This isn't really a Derby question, it's more of a web/Javascript >>>> question. >>>> >>>> There is no way to push data to a client. The request always originates >>>> on the client. >>>> >>>> That said, IF you are so inclined you can use Ajax type calls to poll a >>>> servlet on the server on a regular interval to check for updates. It would >>>> still be polling, though. Not event-based. >>>> >>> >>> Hi, >>> >>> While the original request has to originate from the client, you don't have >>> to have the client poll on regular intervals - you can use something like >>> long poll or streaming to basically get an event-based system. Note that >>> this requires some software on the server side, and as most things these >>> techniques have their challenges. >>> Besides from the link already mentioned, you can have a look at Atmosphere ( >>> https://atmosphere.dev.java.net/ ) and maybe post a question there or on a >>> similer mailing list / forum. >>> >>> >>> Hope this helps, >>> -- >>> Kristian >>>> >>>> I would look at prototype if you want to start leveraging Ajax. >>>> http://www.prototypejs.org/ It's a good place to start. >>>> >>>> I would be very careful about having JS continuously polling your server >>>> though. If you have lots of clients you will end up with lots of requests >>>> to handle. That code has to be very efficient. >>>> >>>> >>>> On Feb 12, 2010, at 11:17:22 AM, albertkao wrote: >>>> >>>> >>>>> >>>>> The goal is to refresh a JSP web page on a web browser when the Derby DB >>>>> on >>>>> the server is changed. >>>>> The rate of database change is 1-10 times per hour. >>>>> The record size is about 1000 bytes. >>>>> The user use the browser to modify the data and write back to the Derby >>>>> DB. >>>>> The web server is tomcat. >>>>> I am thinking of comet programming - pushing data from the server to >>>>> client >>>>> when the Derby DB is changed. >>>>> Is that a good idea? >>>>> How to do that with javascript or java? >>>>> Any sample code or tutorial? >>>>> -- >>>>> View this message in context: >>>>> http://old.nabble.com/refresh-JSP-webpage-when-Derby-DB-is-changed-tp27565891p27565891.html >>>>> Sent from the Apache Derby Users mailing list archive at Nabble.com. >>>>> >>>>> >>>> >>>> >>> >>> > >
