Hi Paul Thanks again for your response. I have a little doubt left, which I would like to clarify here. Please apolozise, if I am asking the same question again.
I have concluded that for Dynamic content fetching portlets (Web Page Portlets or RSS Portlts), it is NOT mandatory to have Java Run Time Environment at browser at the CLIENT side? Whereas JRE is needed at the SERVER side where Jetspeed engine is running. Please correct me if I am wrong. Now assume, if these portlets (RSS, Web Page) is running at the server, where there is no JRE at CLIENT browser, then how Jetspeed engine will know the client status (is it alive)? And then how Jetspeed engine will manage to throw the information after regular interval at the client browser using simply HTTP connection? I shall be highlt obliged for your kind response. Regards Deep -----Original Message----- From: Paul Spencer [mailto:[EMAIL PROTECTED]] Sent: Saturday, June 29, 2002 4:38 PM To: Jetspeed Users List Subject: Re: FW: Is Syndication of content Browser Dependent? DeepSangeet wrote: > Hi Paul > Thanks for your response. > > Well as you mentioned, "Jetspeed and the include portlets do note require > Java on the client > end." > > My question is, what will happen once user view from IE ver7.0, where I > believe, it doesn't support Java Run Time environment! As long as you portlet do not sent java to the browser, i.e. IE 7.0, you will not have a problem. As to the SERVER side which is where jetspeed run, you will need a Java runtime environment. I suspect their will always be a Java Runtime available for windows. Sun is currently providing one, in addition to M$. > > Please help me to clear my doubt & kindly correct me if I am wrong. > > This problem will arise only once user view portlets such as Dynamic Content > Fetching that need java run time environment. For rest portlet types, we > don't need JRE at client side. Am I correct? Jetspeed and the Java runtime are running on the SERVER. > > If I am correct, how we can overcome this drawback? Do you think this is the > limitation of the HTTP connetion where it doesn't remember the client's > identity or status? > > I shall be highly obliged for your kind response. > > Regards > Deep > > > > > > > -----Original Message----- > From: Paul Spencer [mailto:[EMAIL PROTECTED]] > Sent: Saturday, June 29, 2002 5:05 AM > To: Jetspeed Users List > Subject: Re: Is Syndication of content Browser Dependent? > > > Please post a message only ONCE. > > DeepSangeet wrote: > > >>Hi >>Can anyone please help me to answer the following question: >> >>Is "Dynamic Content Updating" is a Brower Dependent? >> >>I know fetching the site is independent of browser. >>It has been written in Web Page Portlet, "The web page will be loaded by >> > the > >>Jetspeed server, not the user's web browser, and maintained by the cache >>subsystem. Since Jetspeed is loading the page, no information from the >>user's browser, like cookies, will be provided to the web server." >> >>But what about the repetative updating of content? >> > > This is done in the WebPagePortlet as described above, "maintained by > the cache subsystem" > > ? Do we need the java run > >>time environment at the browser? >> > > Jetspeed and the include portlets do note require Java on the client > end. Jetspeed does not prevent a portlet from using java, or any other > technology, on the client end. > > >>If yes, then is it not this technology have >>the limitation? If not, please help me to understand how dynamic >>syndication is taking place? I mean how are we keeping the client alive? >> > And > >>how the server do the HTTP post? >> > > > See the previous comment > > >>I shall be highly obliged if you can provide me any related >> > site/information > >>answering to my query in more detail way which will help me to understand >>this technology. >> > > > http://jakarta.apache.org/jetspeed/site/index.html > http://jakarta.apache.org/jetspeed/site/resources.html > http://www.mail-archive.com/jetspeed-user%40jakarta.apache.org/ > > >>Regards >>Deep >> >> >> > > > Paul Spencer > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
