A popular Indian product FINACLE has an applet which kind of acts as a fat client and each time a customer detail or scheme detail is fetched the whole detail gets downloaded into the applet. But it is not an pure offline application as only the current page can we viewed or changed and every time you try to commit, it searches for the network.
May be it helps taha On Sun, May 3, 2009 at 10:34 PM, Carlo Camerino <cmcamer...@gmail.com> wrote: > hmm, > ya i guess you're right. > --> further i would look into security of gears, how easy is it for > --> someone to access the underlying data store? > > this will be the major issue. > sad to say, i don't know how safe is this > with the branch servers i'm safer. > > i don't really know how google gears plays out yet. > thanks for all the inputs. > > On Mon, May 4, 2009 at 12:25 AM, Igor Vaynberg <igor.vaynb...@gmail.com> > wrote: >> >> you already said each branch has their own server, so why not simply >> make this server sync to the central server when the connection is >> available. >> >> your argument for administering cost does not make sense as you are >> heading down the fat client path so instead of having a single server >> per branch to administer you will have every fat client app instance >> to administer. >> >> further i would look into security of gears, how easy is it for >> someone to access the underlying data store? >> >> -igor >> >> On Sun, May 3, 2009 at 4:35 AM, Carlo Camerino <cmcamer...@gmail.com> wrote: >> > just to add, we don't have any plan of exposing this to the public (retail) >> > but rather only to people within organization. >> > so maybe we could have some sort of control. >> > I don't know the implications of opening offline banking applications to >> > the >> > public yet :P and i don't really see any usecase for this type of >> > applications for now. >> > >> > btw, it's not that easy to target a larger set of people if you are using >> > Fat Web clients. >> > Just my two cents. bandwidht, cpu considerations, etc... maybe it depends >> > on >> > your geographical location >> > >> > On Sun, May 3, 2009 at 7:27 PM, Carlo Camerino <cmcamer...@gmail.com> >> > wrote: >> > >> >> There are really a lot of things i have to consider. >> >> Especially security. >> >> >> >> Here Are Some Of The Considerations I Guess >> >> >> >> 1.) To View (Subset) Records But Not Edit Or Delete Them >> >> 2.) Users must not be able to edit reference tables. Tables that are >> >> referenced by others. >> >> 3.) Users must be able to enter transactions(Purely Insert,Transaction >> >> Recording Only) with client side validation and observance of limits and >> >> rules of course which were defined during online mode. ( Store This Queue >> >> Somewhere) >> >> >> >> I'm not reallyh sure that I want to go through with this however, this is >> >> just a prototype idea. >> >> >> >> >> >> On Sun, May 3, 2009 at 4:55 PM, Johan Compagner >> >> <jcompag...@gmail.com>wrote: >> >> >> >>> I cannot believe that a typical wicket application (and a banking app >> >>> fall under that category) does well in offline mode, to me offline >> >>> mode works if the app is just about personal data (like gmail for your >> >>> email) because if that is not the case and loads of none peronal == >> >>> shared data is used, how are you pushing that to the client? Maybe if >> >>> the data is not thah much (not very likely in a banking app if you >> >>> ask me) then you can push it to the client. But then when he gets >> >>> online again you have to merge everything and resolve conflicts in the >> >>> data... >> >>> >> >>> But wicket doesnt really play well for this at all. GWT or just >> >>> another fat client like air or just java webstart would be better >> >>> >> >>> On 03/05/2009, Carlo Camerino <cmcamer...@gmail.com> wrote: >> >>> > hmm, you have a point here.however, every requirement is different. >> >>> > >> >>> > I know that it may sound weird, but still I believe that it depends on >> >>> the >> >>> > nature of the application. >> >>> > There are lots of types of applications that banks use. >> >>> > Some I know would have to always have a central server managing it. >> >>> > >> >>> > There are different types of Technical Architectures that we cater for >> >>> in >> >>> > our applications. >> >>> > There are some applicationms that always require online mode regardless >> >>> adn >> >>> > there are applications that the user just >> >>> > needs to be able to view customer information ,etc.... >> >>> > >> >>> > >> >>> > actually it's hard to decide here. >> >>> > on the downside, I heard that GWT consumes a lot of resources on the >> >>> client >> >>> > side, it's also a consideration. >> >>> > >> >>> > Failsafe servers are of course an option but again, the network is >> >>> > still >> >>> a >> >>> > factor here. >> >>> > For example a very slow connection to the central server makes my >> >>> > productivity a lot less. >> >>> > Some places suffer from low bandwidth, unreliable networks, etc... >> >>> > >> >>> > I saw the value of distributed or offline applications that uses >> >>> > synchronization. >> >>> > It will be harder for the developers of course sicne they have to cater >> >>> to >> >>> > two modes. >> >>> > On Sun, May 3, 2009 at 1:55 PM, Vladimir K <koval...@gmail.com> wrote: >> >>> > >> >>> >> >> >>> >> I would install failsafe cluster rather satisfying every client >> >>> >> request >> >>> >> about >> >>> >> offline workability. You may end up implementing all the front-end and >> >>> >> middle-end features in offline mode :) >> >>> >> >> >>> >> I believe offline mode should be used with care. The email >> >>> >> applications >> >>> >> are >> >>> >> by nature offline. If you are certain that what the user does is >> >>> offline >> >>> >> by >> >>> >> nature - implement it. If you have concerns that it should be involved >> >>> >> into >> >>> >> transaction (I mean a bit wider meaning than DB transaction) - >> >>> implement >> >>> >> it >> >>> >> online and think about fail-safe servers. >> >>> >> >> >>> >> Concerning front-end and middle-end, AFAIK, every unit of work is a >> >>> >> transaction which is done with multi-level authorization, including >> >>> >> business >> >>> >> authorization. You either implement all the authorization offline >> >>> >> (insecure >> >>> >> at all, and impossible in some cases) or defer authorization untill >> >>> online >> >>> >> mode (non-transactional). If a request of some client was satisfied >> >>> >> (in >> >>> >> offline mode) and then hasn't passed online authorization (for >> >>> >> instance >> >>> it >> >>> >> violates some limits which can be thruly calculated on the server side >> >>> >> only), you will have to call the client and tell him your appologises >> >>> (or >> >>> >> not directly you, then the bank. but the bank will then call you and >> >>> tell >> >>> >> you something awesome). >> >>> >> >> >>> >> Or just tell me the name of the bank. I will never become its client >> >>> >> :) >> >>> >> >> >>> >> >> >>> >> Carlo Camerino wrote: >> >>> >> > >> >>> >> > it's not for the public to use. but rather for people within the >> >>> banks. >> >>> >> > internal applications. sometimes central connection is not >> >>> >> > available. >> >>> >> > >> >>> >> > On Fri, May 1, 2009 at 9:37 PM, James Carman >> >>> >> > <jcar...@carmanconsulting.com>wrote: >> >>> >> > >> >>> >> >> Are you sure a banking application would be the right place for a >> >>> >> >> gears-based implementation? Wouldn't it be kinda important to make >> >>> >> >> sure the main server knows where everything is, when money is >> >>> >> >> concerned? >> >>> >> >> >> >>> >> >> On Fri, May 1, 2009 at 4:04 AM, Carlo Camerino < >> >>> cmcamer...@gmail.com> >> >>> >> >> wrote: >> >>> >> >> > Hi, >> >>> >> >> > >> >>> >> >> > Is there any project which has Wicket And Google Gears >> >>> Integration? >> >>> >> >> > Wicket has really done a lot of us in speeding up development >> >>> time. >> >>> >> >> Coming >> >>> >> >> > from a struts we saw the power of Wicket in terms its reusability >> >>> and >> >>> >> >> i've >> >>> >> >> > noticed that >> >>> >> >> > wicket already did most of the tasks that we would have to >> >>> manually >> >>> >> >> > do >> >>> >> >> using >> >>> >> >> > struts application, like session timeouts, redirects, etc.... >> >>> >> >> > >> >>> >> >> > One of our main concerns however are that clients >> >>> >> >> > are asking for our applications to be available even if the >> >>> network >> >>> >> >> > is >> >>> >> >> down >> >>> >> >> > or if the central server is down.. >> >>> >> >> > Currently we implemented our applications in a distributed >> >>> >> >> > fashion >> >>> >> >> wherein >> >>> >> >> > every branch ( Remote Location) has its own server. >> >>> >> >> > However, this has implications of cost and administration issues. >> >>> >> >> > However, if offline mode is enabled we can just begin syncing >> >>> right. >> >>> >> >> > >> >>> >> >> > I think that Wicket WIth Google Gears Application will make it >> >>> even >> >>> >> >> better . >> >>> >> >> > >> >>> >> >> > >> >>> >> >> > I think this is really a plus when it comes to marketing it to >> >>> >> >> customers. >> >>> >> >> > Most of the applications that we create our banking applications >> >>> and >> >>> >> >> any >> >>> >> >> > downtime is costing our clients. >> >>> >> >> > >> >>> >> >> > Hopefully we can also do this to offload the central servers and >> >>> to >> >>> >> put >> >>> >> >> > processing into client machines. >> >>> >> >> > >> >>> >> >> > One large problem I see though is that most code wil have to be >> >>> moved >> >>> >> >> to >> >>> >> >> the >> >>> >> >> > Browser Layer. >> >>> >> >> > I'm thinking of how to create a wicket application which is >> >>> >> >> > mostly >> >>> >> >> > run >> >>> >> >> by >> >>> >> >> > java classes work on the client side. >> >>> >> >> > Looks as if there will be a lot of code changes... >> >>> >> >> > I'm not really sure if it would be a totally different >> >>> >> >> > programming >> >>> >> >> model. >> >>> >> >> > >> >>> >> >> > Anyone out there tried to integrate Gears And Wicket >> >>> >> >> > >> >>> >> >> > Carlo >> >>> >> >> > >> >>> >> >> >> >>> >> >> >> >>> --------------------------------------------------------------------- >> >>> >> >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> >>> >> >> For additional commands, e-mail: users-h...@wicket.apache.org >> >>> >> >> >> >>> >> >> >> >>> >> > >> >>> >> > >> >>> >> >> >>> >> -- >> >>> >> View this message in context: >> >>> >> >> >>> http://www.nabble.com/Wicket-Offline-Applications-tp23329675p23352910.html >> >>> >> Sent from the Wicket - User mailing list archive at Nabble.com. >> >>> >> >> >>> >> >> >>> >> --------------------------------------------------------------------- >> >>> >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> >>> >> For additional commands, e-mail: users-h...@wicket.apache.org >> >>> >> >> >>> >> >> >>> > >> >>> >> >>> --------------------------------------------------------------------- >> >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> >>> For additional commands, e-mail: users-h...@wicket.apache.org >> >>> >> >>> >> >> >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
