Hi Raphael, --- "Luta, Raphael (VUN)" <[EMAIL PROTECTED]> wrote: > > If I understand correctly your request in regards to the > JSR 168, you would like to be able to develop a client based portal > that leverages the portlet components developped against the JSR168 > API. Is that correct ? > > I think that what you can do in this case is implementing > a portal "server" on the client, with client side technologies that > interact with a remote portlet container over the network, for > example > through WSRP. In such a setup, your client can control exactly the > aggregation behavior and still leverage any JSR 168 portlets through > WSRP. > > Since JSR 168 assumes a server-based aggregation process, it can not > answer alone your requirement but OTOH I don't think it's a > showstopper > since WSRP will perfectly handle this requirement. > > Am I missing something here ? >
Are you suggesting that in order to accomodate client-side technologies that a browser plugin 'portal server' would be necessary? Users would reject this outright. I really don't see how this would solve the problem. It is the whole interaction model that is the problem, not where the 'portal server' lives. rgds, Gerry Reno __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
