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
