Mike, It appears that TFW has gone the way of the dinosaur.
As far as anything new, I'm not aware of anything. To me, the reason why this aspect of development is (if not dead) at a crawl is: * there are issues with table based layout of portlets regarding Javascript. There are IFrame portlets but then there is a look and feel problem with CSS. * Basically, the javascript namespace collides with other portlets (using a table layout). The browser (IE, Firefox, Opera, etc) would need to change for this technology. The bottom line is, a browser would likely need to be created for WSRP or similar technology. * Cookies aren't supported so state management would really have to be reassessed. * the architecture is likely to be too slow. Waiting for all these portlets from remote sites to load can really be a drag. I'm sure the internet will be hundreds of times faster someday so this will not be an issue over time. * URL rewriting has its problems too. The current implementation is a simple search and replace where it should be a context based search and replace. At 20000 feet, I hope this info is helpful. James Moliere -----Original Message----- From: Michael Gebhart [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 28, 2006 8:05 AM To: [email protected] Subject: RE: Alternative for WSRP Hi, thanks for you answer! But TFW seems to be dead, right? Can't find much useful information about it. Well my problem is (maybe you can help me a bit here): There is WSRP4J and some portals can work as wsrp producer and/or consumer. Ok, fine. I've read a lot of blogs and discussions and many people were not satisfied with WSRP in the current version. (Interportlet communication and so on). Now the WSRP 2.0 is in development since several years and in parallel the JSR-268. But for me it looks like WSRP is not really important for developers. There is no development for a reference implementation of WSRP 2.0 yet, only the pluto project tries to implement JSR-268 (although JSR-268 isn't finished yet). This is not any kind of criticism. I only wonder: If WSRP is not the point of interest: Is there any other technology which is doing similar things, but maybe better than WSRP? Or is there no need for anything like WSRP? Maybe portals aren't the solution we are looking for? Maybe I am completely wrong and WSRP is simply the best and the OASIS only delays the release of WSRP 2.0 since years :) I am really interested in other opinions! Greetings Mike > Mike, > > There was a technology called, "Task Force Web" (TFW) that did similar > things as WSRP but was more compatible with the technology of today. > For example: > > . URL rewriting was done but only for HTML pages and the pages > were contextually rewritten. > > . The services were simply other web sites. > > . The portlets rendered within IFrames instead of html tables. > The advantage of this is that javacript would work properly in each > page. The problem was that cascading style sheets were always needed > to be inserted into each portlet to obtain a consistent look and feel > through the portal pages. > > . Cookies were allowed and managed on the server (portal) that > the client connected to. > > . A UDDI registry was created to find services so users can > find the services they need and render them in their respective > portlet. > > > > I hope this is helpful. > > > > > > -----Original Message----- > From: Michael Gebhart [mailto:[EMAIL PROTECTED] > Sent: Monday, November 27, 2006 12:34 PM > To: [email protected] > Subject: Alternative for WSRP > > > > Hi, > > > > I am currently exploring WSRP, especially the next specification 2.0. > Do > > you know, if there is any alternative for WSRP? Anything, that is > doing > > similar things? That I can include portlets via webservices? > > > > Greetings > > > > Mike > > > > > > __________ NOD32 1886 (20061127) Information __________ > > > > This message was checked by NOD32 antivirus system. > > http://www.eset.com > > > > __________ NOD32 1887 (20061128) Information __________ This message was checked by NOD32 antivirus system. http://www.eset.com
