You don't necessarily need to do serverside code. Encode an iframe in an iframe. Data from the inside iframe might html or xml, but the overlying iframe allows you to get the data inside of it. This works well if you're doing a single "get" type. The inside Iframe can be a hardcoded URL, or somesuch. The inside iframe is understood to be in the same domain, but is referencing a url in a differing domain.
To dynamically make it work, ala Ajax like, you'd need to inject the iframe url code into the dom, and then simply reload/refresh the outside url.
I haven't done the 2nd part, but if I'm not mistaken, that's basically what google's doing for their gmailchat for firefox (and using a ms activex object for ie).
The advantage would be less domino server load, but the disadvantage is say you're working in a closed environment where _some_ end-user pc's may be closed off to outside access, but perhaps the server, and most others in the company are not - basically you're stopping them from getting the content.
You don't necessarily need to do serverside code. Encode an iframe in an iframe. Data from the inside iframe might html or xml, but the overlying iframe allows you to get the data inside of it. This works well if you're doing a single "get" type. The inside Iframe can be a hardcoded URL, or somesuch. The inside iframe is understood to be in the same domain, but is referencing a url in a differing domain.
To dynamically make it work, ala Ajax like, you'd need to inject the iframe url code into the dom, and then simply reload/refresh the outside url.
I haven't done the 2nd part, but if I'm not mistaken, that's basically what google's doing for their gmailchat for firefox (and using a ms activex object for ie).
The advantage would be less domino server load, but the disadvantage is say you're working in a closed environment where _some_ end-user pc's may be closed off to outside access, but perhaps the server, and most others in the company are not - basically you're stopping them from getting the content.