Re: Secure Portlets
Raphael, I agree that it would be a complete waste of resources if all the portlet does is providing the SAX/DOM interface and streaming it. But I am not saying that. The idea is that such a derived portlet does everything required/desired on post-processing the events and only then streaming it. It's just that it is not the portal itself dealing with the events, but a special portlet. And the best is: this portlet would run on *any* implementation of a portlet container. I imagine something like this: Portlet -- getPrintWriter |-- SAXlet (c) |-- getContentHandler |-- getLexicalHandler |-- DOMet |-- getDocumentNode |-- ECSlet |-- getBaseElement |-- I do think there is a certain elegance in this approach If you want I can prepare Javadoc for this. As you probably know, you can (almost) always map higher levels to lower levels but (virtually) never lower levels to higher levels. That's why the byte stream ultimately has to be the implementation. I am glad you agree to that. For the SAX case, I don't think it is a matter of adding one or two methods to the PortletResponse. That's why I am reluctant to make the mods just yet. How do we specifiy the stylesheet(s) to be used (if any)? How do we supply new parsers (if any)? How do we make sure that tomorrow we don't need to add support for DOM or ECS? If we support SAX, we should probably give the latter two a chance too. But add support for each of them in PortletResponse? I don't think that's a good idea. I still don't see where Jetspeed parses portlet output. And I continue to disagree with your 80% statement. What assumptions are you talking about for WML? To some extent every portlet has to make assumptions about controls and controllers, because every portlet only delivers markup fragments which need to be (and hopefully are) completed by controls and controllers. But I guess that's not what you mean If you (and Santiago) are still not convinced by the above solution, I suggest we do a vote on this particular issue. As I wrote before, I am happy to add those methods if for a good reason -- and a majority on the mailing list *is* a good reason. Cheers, Thomas B. - Original Message - From: "Raphal Luta" [EMAIL PROTECTED] To: "JetSpeed" [EMAIL PROTECTED] Sent: Sunday, February 11, 2001 14:33 Subject: Re: Secure Portlets "Thomas F. Boehme" wrote: Santiago, Raphael, What's wrong with doing the things you suggested in a derived portlet? Because the stream is the final result you can map (virtually) any other method like SAX, DOM, ECS, etc to the stream. This way the interface is not complicated any further, and portlet container writers are not burdened with several implementation paths. Also, doing this in derived portlets, mean we can easily add other mechanism including Cocoon2 (so I think), without any modifications to the API! Sounds very appealing to me Doing this with a derived portlet is a big performance hit for implementations that would process natively SAX events (for example Cocoon) because you would have a event - byte streem - event serialization/parse process which is a complete waste of resources. In any case, the dual implementation paths is very easy to deal with since you just have to convert the stream you don't want to deal with into the stream you're intersted (that means either parsing the byte stream or serializing the event stream). Jetspeed 1.3 implementation will certainly use the byte stream path because it's a natural fit with Turbine and Velocity but if I ever want to write an alternate implementation, I don't want to be constrained by the API just because it was optimized for one specific implementation. I disagree with your assumption that 80% of the portlet markup needs to parsed anyway. If that were so something is fundementally wrong. At any rate, Jetspeed 1.3a1 does not parse any of its generated markup for whatever reason, and it does what it is supposed to do. My assumption is that for about 80% of the requests, the portal will need to post-process the portlets output. Jetspeed 1.3a1 does post-process the markup but is very poor at providing a stable portlet environment: any portlet can competely screw the entire portal page and I don't even speak about WML support where the portlets need to make assumptions on the controls/controllers used in order to provide valid markup. Don't tell me this is good, reliable and solid design. I don't understand what really bothers you in adding the additional methods in the PortletResponse : - the additionnal implementation constraints are minimal - it does not influence the performance of native byte stream implementations - it broadens the scope of the API since it makes it more efficient on some possible platforms So what's the issue ? -- Raphal Luta - [EMAIL PROTECTED] Vivendi Universal Networks - Services Manager / Paris -- -
Re: Secure Portlets
At 11:39 12/02/2001 +0100, you wrote: Raphael, I agree that it would be a complete waste of resources if all the portlet does is providing the SAX/DOM interface and streaming it. But I am not saying that. The idea is that such a derived portlet does everything required/desired on post-processing the events and only then streaming it. It's just that it is not the portal itself dealing with the events, but a special portlet. And the best is: this portlet would run on *any* implementation of a portlet container. I imagine something like this: Portlet -- getPrintWriter |-- SAXlet (c) |-- getContentHandler |-- getLexicalHandler |-- DOMet |-- getDocumentNode |-- ECSlet |-- getBaseElement |-- I do think there is a certain elegance in this approach If you want I can prepare Javadoc for this. I understand your point but what you propose is in fact reimplementing any functionalities already available in a native SAX site manager (like cocoon 2) as a portlet so that it can be portable to any container. That doesn't make sense to me. As you probably know, you can (almost) always map higher levels to lower levels but (virtually) never lower levels to higher levels. That's why the byte stream ultimately has to be the implementation. I am glad you agree to that. I agree only as far as Jetspeed 1.3 is concerned. I can definitely see other implementations where the link between portlet and portal is high level and only converted to low level by the portal at the end of its processing. For the SAX case, I don't think it is a matter of adding one or two methods to the PortletResponse. That's why I am reluctant to make the mods just yet. How do we specifiy the stylesheet(s) to be used (if any)? How do we supply new parsers (if any)? You don't. Why would a portlet care about this ? It's a portal implementation job to know what to do with the event stream and how to process it. The Portlet API just has to make high-level communication possible between portal and portet. How do we make sure that tomorrow we don't need to add support for DOM or ECS? If we support SAX, we should probably give the latter two a chance too. But add support for each of them in PortletResponse? I don't think that's a good idea. The Portlet API is stream based we'll only consider stream options. It's trivial to convert byte streams to string buffers (ECS ConcreteElement is a specialized buffer) or event streams to object tree (DOM). They're just 2 faces of the same coin, once you have one you can very easily get the other if required. I still don't see where Jetspeed parses portlet output. And I continue to disagree with your 80% statement. What assumptions are you talking about for WML? To some extent every portlet has to make assumptions about controls and controllers, because every portlet only delivers markup fragments which need to be (and hopefully are) completed by controls and controllers. But I guess that's not what you mean This is what I mean. In an ideal aggregation system, portlet should not be aware of how they'll be aggregated. For example, rather than simply outputting its HTML content in a table tag, a portlet can simply output a complete HTML document (with head and body) and the portal can simply strip head tags and replace body by either a table or a div. The same kind of process can be done with other markup languages but it does require post-processing of the portlet output. This is a very important choice: Should portlets be allowed to output document fragments ? If so, how can they make sure that these fragments are correctly processed whatever the portal implementation they're running on ? One may want an HTML table as root element for the output while the other will want a div, or talking WML must a portlet output a full wml deck, a card, a set of card or simply a card content ? This is very important because you can't nest card like you can nest table. The only way I can see this working across implementations is to mandate that portlet output full documents with portal post-processing in order to fit the output in an aggregated document. If you (and Santiago) are still not convinced by the above solution, I suggest we do a vote on this particular issue. As I wrote before, I am happy to add those methods if for a good reason -- and a majority on the mailing list *is* a good reason. OK, I think the arguements for both sides have run for long enough, I'll send a vote request in a separate mail because some people probably didn't follow our discussions so far ;) -- Raphal Luta - [EMAIL PROTECTED] Vivendi Universal Networks - Services Manager / Paris -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: Secure Portlets
[EMAIL PROTECTED] wrote: [EMAIL PROTECTED]">Santiago Gala wrote: We are already supporting, in not yet public code, HTML and WML with thesame PSML file using a final media adapted XSLT transformation. Allportlets generate XML, and the aggregation process is a matter offollowing the PortletSet structure and generating SAX events on the fly.This events are processed by a final Stylesheet, that formats theoutput. I think that the code is even simpler than the current code. Santiago,how many personalized portal pages per second can you serve using thisapproach and what is the memory usage and the number of objects created perrequest ?Best regards, We are not able to test until when we get it working with just released Xalan2 (much more adapted to SAX XSLT transformations). But I will tell you soon. In any case, I would not expect it to be slower than current Jetspeed. And experience tells me that if it is not ready for high traffic portals now (which remains to be seen), it will be in one or two generations of hardware (read six months / one year). I think the revolution now is on getting people aware that style should be separated from content as far as possible, as they are serving only HTML now, but they will be serving WML, VoiceML, XHTML (in several variants) real soon. -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: List Help?: [EMAIL PROTECTED]
Re: Secure Portlets
Santiago Gala wrote: (another HTML message slipped)... I think I found the way to switch off HTML from mozilla at the end... Sorry. -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: Secure Portlets
"Thomas F. Boehme" wrote: Santiago, Raphael, What's wrong with doing the things you suggested in a derived portlet? Because the stream is the final result you can map (virtually) any other method like SAX, DOM, ECS, etc to the stream. This way the interface is not complicated any further, and portlet container writers are not burdened with several implementation paths. Also, doing this in derived portlets, mean we can easily add other mechanism including Cocoon2 (so I think), without any modifications to the API! Sounds very appealing to me Doing this with a derived portlet is a big performance hit for implementations that would process natively SAX events (for example Cocoon) because you would have a event - byte streem - event serialization/parse process which is a complete waste of resources. In any case, the dual implementation paths is very easy to deal with since you just have to convert the stream you don't want to deal with into the stream you're intersted (that means either parsing the byte stream or serializing the event stream). Jetspeed 1.3 implementation will certainly use the byte stream path because it's a natural fit with Turbine and Velocity but if I ever want to write an alternate implementation, I don't want to be constrained by the API just because it was optimized for one specific implementation. I disagree with your assumption that 80% of the portlet markup needs to parsed anyway. If that were so something is fundementally wrong. At any rate, Jetspeed 1.3a1 does not parse any of its generated markup for whatever reason, and it does what it is supposed to do. My assumption is that for about 80% of the requests, the portal will need to post-process the portlets output. Jetspeed 1.3a1 does post-process the markup but is very poor at providing a stable portlet environment: any portlet can competely screw the entire portal page and I don't even speak about WML support where the portlets need to make assumptions on the controls/controllers used in order to provide valid markup. Don't tell me this is good, reliable and solid design. I don't understand what really bothers you in adding the additional methods in the PortletResponse : - the additionnal implementation constraints are minimal - it does not influence the performance of native byte stream implementations - it broadens the scope of the API since it makes it more efficient on some possible platforms So what's the issue ? -- Raphal Luta - [EMAIL PROTECTED] Vivendi Universal Networks - Services Manager / Paris -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: Secure Portlets
At 13:10 08/02/2001 +0100, you wrote: Raphael, I think I do understand what you mean. "Well-formed XML" simply implies that the output of the portlet will be parseable by an XML parser but does not enforce (or even expect) any DTD or schema compliance. How on earth do you want to write a parser for a language that you don't know. Leaving out the DTD only means that the portlet is not technically bound, it would still need to compliant to some language. Unless --- unless you are talking about different parsers for mime-type which the aggregation module may be to handle. Even if the API does not mandate a DTD compliance, in order to aggregate and post-process the documents the portal will always assume that the portlet will output a known format (XHTML, WML, etc...). However this a portal implementation issue. But then, parsing the markup - even if it was well-formed - is an expensive operation. I don't think we should enforce this burden onto the portal just because we are not able to provide utility functions to do link substitution in place (that is, right in the template). Also, you cannot leave this decision open, because a portlet that relies on the portal to do certain substitions would not run properly on a portal that goes for performace and leaves everything through. I think this discussion is crucial to the future of Jetspeed. Looking forward to more arguments... It is a very important choice. I agree that parsing may be an expensive operation (although I believe SAX parsing is quite efficient) but, since I base my reasoning on the premise that in 80% of the requests, the portal will *have* to parse the result in order to aggregate correctly the portlet output, it's a cost that we'll encounter in most case and that we should try to minimize. The portlet to portal communication can be done through - streams - SAX events - string buffers - DOM tree We already decided on a stream oriented API so the choice can be restricted to : - char/byte streams - SAX event streams If the byte stream is chosen as the default communication medium between the portlet and the portal, we will have: if portlet natively generates byte streams : - optimal performance when the portal does not need to post-process output - degraded performance when the portal needs to post-process the output (parsing byte stream) if portlet natively generates XML events : - slightly degraded performance when the portal does not need to post-process output (event stream - byte stream conversion) - very degraded performance when the portal needs to post-process output (event - byte conversion and then reparsing by the portal) If SAX stream is the default communication with the portal: if portlet generates byte streams : - very degraded performance if the protal does not post-process (byte - SAX, then SAX - byte) - degraded performance (parsing byte - event) when the portal postprocess the events if portlets generates SAX events : - slightly degraded perf when no post-processing (event - byte serialization) - optimal performance when post-processing (already parsed) As you can see depending on your expected portal behavior and portlet development tools/methodology, either byte streams or SAX streams are the optimal choice. So my proposal for the Portlet API is : * add a getContentHandlet() method in the PortletResponse interface so that a portlet that wishes so can directly output events to the portal event handler. * allow the portlet either to use getWriter() or getContentHandler() but not both (mutually exclusive use just like ServletResponse.getWriter() and getOutputStream()). That way, it's the portal implementation of the PortletResponse which will decide which is the most efficient way to output data (depending on the whether the implementation parses the char stream into an event stream, serialize the event stream into a char stream or tries to handle natively both). Does that sound reasonable ? -- Raphal Luta - [EMAIL PROTECTED] Vivendi Universal Networks - Services Manager / Paris -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: Secure Portlets
Raphal Luta wrote: At 13:10 08/02/2001 +0100, you wrote: Raphael, I think I do understand what you mean. "Well-formed XML" simply implies that the output of the portlet will be parseable by an XML parser but does not enforce (or even expect) any DTD or schema compliance. How on earth do you want to write a parser for a language that you don't know. Leaving out the DTD only means that the portlet is not technically bound, it would still need to compliant to some language. Unless --- unless you are talking about different parsers for mime-type which the aggregation module may be to handle. Even if the API does not mandate a DTD compliance, in order to aggregate and post-process the documents the portal will always assume that the portlet will output a known format (XHTML, WML, etc...). However this a portal implementation issue. But then, parsing the markup - even if it was well-formed - is an expensive operation. I don't think we should enforce this burden onto the portal just because we are not able to provide utility functions to do link substitution in place (that is, right in the template). Also, you cannot leave this decision open, because a portlet that relies on the portal to do certain substitions would not run properly on a portal that goes for performace and leaves everything through. I think this discussion is crucial to the future of Jetspeed. Looking forward to more arguments... It is a very important choice. I agree that parsing may be an expensive operation (although I believe SAX parsing is quite efficient) but, since I base my reasoning on the premise that in 80% of the requests, the portal will *have* to parse the result in order to aggregate correctly the portlet output, it's a cost that we'll encounter in most case and that we should try to minimize. The portlet to portal communication can be done through - streams - SAX events - string buffers - DOM tree +1. That is what I was trying to say in my previous post. We already decided on a stream oriented API so the choice can be restricted to : - char/byte streams - SAX event streams A DOM oriented portlet could make use of a utility class to convert DOM into SAX (already there in most SAX parsers) If the byte stream is chosen as the default communication medium between the portlet and the portal, we will have: if portlet natively generates byte streams : - optimal performance when the portal does not need to post-process output - degraded performance when the portal needs to post-process the output (parsing byte stream) if portlet natively generates XML events : - slightly degraded performance when the portal does not need to post-process output (event stream - byte stream conversion) - very degraded performance when the portal needs to post-process output (event - byte conversion and then reparsing by the portal) If SAX stream is the default communication with the portal: if portlet generates byte streams : - very degraded performance if the protal does not post-process (byte - SAX, then SAX - byte) - degraded performance (parsing byte - event) when the portal postprocess the events if portlets generates SAX events : - slightly degraded perf when no post-processing (event - byte serialization) - optimal performance when post-processing (already parsed) As you can see depending on your expected portal behavior and portlet development tools/methodology, either byte streams or SAX streams are the optimal choice. So my proposal for the Portlet API is : * add a getContentHandlet() method in the PortletResponse interface so that a portlet that wishes so can directly output events to the portal event handler. Don't forget getLexicalHandler() I think it is the only way to manage CDATA and entities. * allow the portlet either to use getWriter() or getContentHandler() but not both (mutually exclusive use just like ServletResponse.getWriter() and getOutputStream()). In case of portlets that use SAX, I have the name SAXlets (c) Santiago Gala 2000. Look in the archives for the post where I copyrighted the name implicitly last year :) These methods could be put into servlet API, and I think they should. Something like an interface javax.servlet.sax.SAXlet. Servlets implementing this interface can be REQUESTED by the container to use getContentHandler and forbidden to use getWriter/getOutputStream. This again (c) Santiago Gala 2001. Feel free to quote it, since it is under Apache license. That way, it's the portal implementation of the PortletResponse which will decide which is the most efficient way to output data (depending on the whether the implementation parses the char stream into an event stream, serialize the event stream into a char stream or tries to handle natively both). Does that sound reasonable ? +1024. I see you have put all my current
Re: Secure Portlets
At 15:39 09/02/2001 +0100, you wrote: Raphal Luta wrote: We already decided on a stream oriented API so the choice can be restricted to : - char/byte streams - SAX event streams A DOM oriented portlet could make use of a utility class to convert DOM into SAX (already there in most SAX parsers) Yes, converting static - stream structures (either DOM - SAX or buffers - streams) is easy to do and there are already a lot of utility code for doing this. If the byte stream is chosen as the default communication medium between the portlet and the portal, we will have: if portlet natively generates byte streams : - optimal performance when the portal does not need to post-process output - degraded performance when the portal needs to post-process the output (parsing byte stream) if portlet natively generates XML events : - slightly degraded performance when the portal does not need to post-process output (event stream - byte stream conversion) - very degraded performance when the portal needs to post-process output (event - byte conversion and then reparsing by the portal) If SAX stream is the default communication with the portal: if portlet generates byte streams : - very degraded performance if the protal does not post-process (byte - SAX, then SAX - byte) - degraded performance (parsing byte - event) when the portal postprocess the events if portlets generates SAX events : - slightly degraded perf when no post-processing (event - byte serialization) - optimal performance when post-processing (already parsed) As you can see depending on your expected portal behavior and portlet development tools/methodology, either byte streams or SAX streams are the optimal choice. So my proposal for the Portlet API is : * add a getContentHandlet() method in the PortletResponse interface so that a portlet that wishes so can directly output events to the portal event handler. Don't forget getLexicalHandler() I think it is the only way to manage CDATA and entities. You're right, getLexicalHandler() is also needed. * allow the portlet either to use getWriter() or getContentHandler() but not both (mutually exclusive use just like ServletResponse.getWriter() and getOutputStream()). In case of portlets that use SAX, I have the name SAXlets (c) Santiago Gala 2000. Look in the archives for the post where I copyrighted the name implicitly last year :) These methods could be put into servlet API, and I think they should. Something like an interface javax.servlet.sax.SAXlet. Servlets implementing this interface can be REQUESTED by the container to use getContentHandler and forbidden to use getWriter/getOutputStream. This again (c) Santiago Gala 2001. Feel free to quote it, since it is under Apache license. Sorry to break your copyright, but this structure has already been proposed by Assaf Arkin as XMLServlet extension of the servlet API ;-) You can find it in Castor. That probably means it's a good idea :) That way, it's the portal implementation of the PortletResponse which will decide which is the most efficient way to output data (depending on the whether the implementation parses the char stream into an event stream, serialize the event stream into a char stream or tries to handle natively both). Does that sound reasonable ? +1024. I see you have put all my current thinking e-black on e-white. I think Thomas misunderstood my previous post, but this was exactly what I meant. If you want a good laugh provided by our friends at Xo3: http://www.portletsapi.org/ -- Raphal Luta - [EMAIL PROTECTED] Vivendi Universal Networks - Services Manager / Paris -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: Secure Portlets
Santiago, Raphael, What's wrong with doing the things you suggested in a derived portlet? Because the stream is the final result you can map (virtually) any other method like SAX, DOM, ECS, etc to the stream. This way the interface is not complicated any further, and portlet container writers are not burdened with several implementation paths. Also, doing this in derived portlets, mean we can easily add other mechanism including Cocoon2 (so I think), without any modifications to the API! Sounds very appealing to me Raphael, I disagree with your assumption that 80% of the portlet markup needs to parsed anyway. If that were so something is fundementally wrong. At any rate, Jetspeed 1.3a1 does not parse any of its generated markup for whatever reason, and it does what it is supposed to do. Cheers, Thomas B. - Original Message - From: "Santiago Gala" [EMAIL PROTECTED] To: "JetSpeed" [EMAIL PROTECTED] Sent: Friday, February 09, 2001 15:39 Subject: Re: Secure Portlets Raphal Luta wrote: At 13:10 08/02/2001 +0100, you wrote: Raphael, I think I do understand what you mean. "Well-formed XML" simply implies that the output of the portlet will be parseable by an XML parser but does not enforce (or even expect) any DTD or schema compliance. How on earth do you want to write a parser for a language that you don't know. Leaving out the DTD only means that the portlet is not technically bound, it would still need to compliant to some language. Unless --- unless you are talking about different parsers for mime-type which the aggregation module may be to handle. Even if the API does not mandate a DTD compliance, in order to aggregate and post-process the documents the portal will always assume that the portlet will output a known format (XHTML, WML, etc...). However this a portal implementation issue. But then, parsing the markup - even if it was well-formed - is an expensive operation. I don't think we should enforce this burden onto the portal just because we are not able to provide utility functions to do link substitution in place (that is, right in the template). Also, you cannot leave this decision open, because a portlet that relies on the portal to do certain substitions would not run properly on a portal that goes for performace and leaves everything through. I think this discussion is crucial to the future of Jetspeed. Looking forward to more arguments... It is a very important choice. I agree that parsing may be an expensive operation (although I believe SAX parsing is quite efficient) but, since I base my reasoning on the premise that in 80% of the requests, the portal will *have* to parse the result in order to aggregate correctly the portlet output, it's a cost that we'll encounter in most case and that we should try to minimize. The portlet to portal communication can be done through - streams - SAX events - string buffers - DOM tree +1. That is what I was trying to say in my previous post. We already decided on a stream oriented API so the choice can be restricted to : - char/byte streams - SAX event streams A DOM oriented portlet could make use of a utility class to convert DOM into SAX (already there in most SAX parsers) If the byte stream is chosen as the default communication medium between the portlet and the portal, we will have: if portlet natively generates byte streams : - optimal performance when the portal does not need to post-process output - degraded performance when the portal needs to post-process the output (parsing byte stream) if portlet natively generates XML events : - slightly degraded performance when the portal does not need to post-process output (event stream - byte stream conversion) - very degraded performance when the portal needs to post-process output (event - byte conversion and then reparsing by the portal) If SAX stream is the default communication with the portal: if portlet generates byte streams : - very degraded performance if the protal does not post-process (byte - SAX, then SAX - byte) - degraded performance (parsing byte - event) when the portal postprocess the events if portlets generates SAX events : - slightly degraded perf when no post-processing (event - byte serialization) - optimal performance when post-processing (already parsed) As you can see depending on your expected portal behavior and portlet development tools/methodology, either byte streams or SAX streams are the optimal choice. So my proposal for the Portlet API is : * add a getContentHandlet() method in the PortletResponse interface so that a portlet that wishes so can directly output events to the portal event handler. Don't forget getLexicalHandler() I think it is the only way to manage CDATA and entities. * allow the portlet either to use getWriter() or getContentHandler() but not both (mutually exclusive use just
Re: Secure Portlets
I can't believe Xo3 did their own thing!!! How do we get them back on board? Thomas B. - Original Message - From: "Raphal Luta" [EMAIL PROTECTED] To: "JetSpeed" [EMAIL PROTECTED] Sent: Friday, February 09, 2001 15:58 Subject: Re: Secure Portlets At 15:39 09/02/2001 +0100, you wrote: Raphal Luta wrote: We already decided on a stream oriented API so the choice can be restricted to : - char/byte streams - SAX event streams A DOM oriented portlet could make use of a utility class to convert DOM into SAX (already there in most SAX parsers) Yes, converting static - stream structures (either DOM - SAX or buffers - streams) is easy to do and there are already a lot of utility code for doing this. If the byte stream is chosen as the default communication medium between the portlet and the portal, we will have: if portlet natively generates byte streams : - optimal performance when the portal does not need to post-process output - degraded performance when the portal needs to post-process the output (parsing byte stream) if portlet natively generates XML events : - slightly degraded performance when the portal does not need to post-process output (event stream - byte stream conversion) - very degraded performance when the portal needs to post-process output (event - byte conversion and then reparsing by the portal) If SAX stream is the default communication with the portal: if portlet generates byte streams : - very degraded performance if the protal does not post-process (byte - SAX, then SAX - byte) - degraded performance (parsing byte - event) when the portal postprocess the events if portlets generates SAX events : - slightly degraded perf when no post-processing (event - byte serialization) - optimal performance when post-processing (already parsed) As you can see depending on your expected portal behavior and portlet development tools/methodology, either byte streams or SAX streams are the optimal choice. So my proposal for the Portlet API is : * add a getContentHandlet() method in the PortletResponse interface so that a portlet that wishes so can directly output events to the portal event handler. Don't forget getLexicalHandler() I think it is the only way to manage CDATA and entities. You're right, getLexicalHandler() is also needed. * allow the portlet either to use getWriter() or getContentHandler() but not both (mutually exclusive use just like ServletResponse.getWriter() and getOutputStream()). In case of portlets that use SAX, I have the name SAXlets (c) Santiago Gala 2000. Look in the archives for the post where I copyrighted the name implicitly last year :) These methods could be put into servlet API, and I think they should. Something like an interface javax.servlet.sax.SAXlet. Servlets implementing this interface can be REQUESTED by the container to use getContentHandler and forbidden to use getWriter/getOutputStream. This again (c) Santiago Gala 2001. Feel free to quote it, since it is under Apache license. Sorry to break your copyright, but this structure has already been proposed by Assaf Arkin as XMLServlet extension of the servlet API ;-) You can find it in Castor. That probably means it's a good idea :) That way, it's the portal implementation of the PortletResponse which will decide which is the most efficient way to output data (depending on the whether the implementation parses the char stream into an event stream, serialize the event stream into a char stream or tries to handle natively both). Does that sound reasonable ? +1024. I see you have put all my current thinking e-black on e-white. I think Thomas misunderstood my previous post, but this was exactly what I meant. If you want a good laugh provided by our friends at Xo3: http://www.portletsapi.org/ -- Raphal Luta - [EMAIL PROTECTED] Vivendi Universal Networks - Services Manager / Paris -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED] -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: Secure Portlets
Raphal Luta wrote: In case of portlets that use SAX, I have the name SAXlets (c) Santiago Gala 2000. Look in the archives for the post where I copyrighted the name implicitly last year :) These methods could be put into servlet API, and I think they should. Something like an interface javax.servlet.sax.SAXlet. Servlets implementing this interface can be REQUESTED by the container to use getContentHandler and forbidden to use getWriter/getOutputStream. This again (c) Santiago Gala 2001. Feel free to quote it, since it is under Apache license. Sorry to break your copyright, but this structure has already been proposed by Assaf Arkin as XMLServlet extension of the servlet API ;-) You can find it in Castor. That probably means it's a good idea :) Yep. You are right. The idea, and the implementation, was already there. Then I can only claim having invented the word SAXlet. A search in Google only returned the two messages of the list in which it was mentioned... :) I still think javax.servlet.sax.SAXlet would be a catching name:) If you want a good laugh provided by our friends at Xo3: http://www.portletsapi.org/ Well, I find in more sad than other thing. Instead of working together in public, they seem to be trying to close and split the community. So bad. Why they did not put their ideas and discussions here? -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: Secure Portlets
on 2/9/01 6:24 PM, "Santiago Gala" [EMAIL PROTECTED] wrote: Well, I find in more sad than other thing. Instead of working together in public, they seem to be trying to close and split the community. So bad. Why they did not put their ideas and discussions here? Just guessing... I would suspect that because at the time when they were working with Jetspeed at ApacheCon, they were really put off by how bad Jetspeed had gotten and probably lost a lot of faith in this project and the quality of software produced here. Now, it isn't up to them to regain the faith on their own. It is up to the people of this project to help them regain the faith by trying to work with them and find a common ground together instead of just expecting them to come back... :-) -jon -- If you come from a Perl or PHP background, JSP is a way to take your pain to new levels. --Anonymous http://jakarta.apache.org/velocity/ http://java.apache.org/turbine/ -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: Secure Portlets
Raphael, I think I do understand what you mean. "Well-formed XML" simply implies that the output of the portlet will be parseable by an XML parser but does not enforce (or even expect) any DTD or schema compliance. How on earth do you want to write a parser for a language that you don't know. Leaving out the DTD only means that the portlet is not technically bound, it would still need to compliant to some language. Unless --- unless you are talking about different parsers for mime-type which the aggregation module may be to handle. But then, parsing the markup - even if it was well-formed - is an expensive operation. I don't think we should enforce this burden onto the portal just because we are not able to provide utility functions to do link substitution in place (that is, right in the template). Also, you cannot leave this decision open, because a portlet that relies on the portal to do certain substitions would not run properly on a portal that goes for performace and leaves everything through. I think this discussion is crucial to the future of Jetspeed. Looking forward to more arguments... Thomas B. - Original Message - From: "Raphal Luta" [EMAIL PROTECTED] To: "JetSpeed" [EMAIL PROTECTED] Sent: Wednesday, February 07, 2001 16:15 Subject: Re: Secure Portlets At 15:05 07/02/2001 +0100, you wrote: Raphael, 1- I still believe it's a bery bad idea not to impose a binding output contract between the portlet and the container - I'd like the API to only allow well-formed XML document output in order to make outpout post-processing as easy as possible (I thought last time we discussed this that the consensus was in implementing this restriction). There certainly wasn't consensus on the issue of an output contract. I am yet to see a convincing example of how such a contract should look like. A small example would be enough. Well-formed XML is *not* the answer to this particular problem. I am happy to repeat my 2 cents of reasoning for this: If the portal requires the portlet to adhere to a portal-set XML, then the portlet is severely limited as to what content it can display. This approach may well work for news-type content, but it is not general-purpose. You can't apply the same DTD to news, wheather, mail, calendar, to-do, stock, and you name it. If on the other hand, the portal asks the portlet to return well-formed XML according to a DTD that the portlet defines, it would also have to return a number of stylesheets for processing. But who is saying that a portlet that doesn't behave with raw markup, suddenly does so when providing a stylesheet? Apart from that, writing a stylesheet is more difficult than creating plain markup. The argument you are giving for the bloated interface kind of applies to this issue as well then. I think you're misreading what I wrote because of our last ApacheCon discussions ;) This has nothing to do with DTD and stylesheets. "Well-formed XML" simply implies that the output of the portlet will be parseable by an XML parser but does not enforce (or even expect) any DTD or schema compliance. My rationale for this is that I believe that, contrary to the servlet container which doesn't modify the servlet generated output, the portlet container will often want to adapt filter the produced content during the aggregation process (for example variable and link substituion in generated forms, markup stripping, output chunking, etc...). If the API enforces that the output will be parseable, this will dramatically reduce the occurence of run-time errors because developpers will need to take care of what they generate. If you consider our main target formats, they are all already XML based (WML, VoxML, SMIL, FO, etc...) except HTML, but producing XHTML instead of straight HTML is not too difficult and we can possibly provide some utility code that portlet writers can use in order to convert existing HTML to XHTML. Now I agree, that restricting output to markup langages may be restrictive since that means no binary or plain text output. I see these as fringe cases since it would be very difficult to aggregate these kinds data by any means (and it's certainly possible to handle these situations by using DTD/schema aware adapters at the layout engine level). -- Raphal Luta - [EMAIL PROTECTED] Vivendi Universal Networks - Services Manager / Paris -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED] -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: Secure Portlets
David, Looks like a missed something on the mailing list... Some of the services listed below, shouldn't be services IMHO. Others I can see, although I am not clear at this stage what methods they should provide. Each service should have a well-definied, agreed-upon interface as part of the Portlet API. All we can provide at this stage is a (set of) service factory method(s). Can put one in, but as long as no services are defined it seems wrong to do so. For example, should the factory just return a reference to a singleton, or should new service objects be created each time? Or do we need both? At any rate, registration should be off - that's definitely implementation detail of the portlet container. If anyone wants to step in and define an abstract service add-on for the Portlet API, you are more than welcome to do so! As it wrote before, adding things is easy, just removing is bad. Yes, David, the Portlet API is Portlet API, not a Portal API. Where did you see PortletData? I should be DynamicData... I didn't understand you window events example... There is (intrinsic) support for windows events in the new Portlet API. But maybe it was an example for something else... Cheers, Thomas B. - Original Message - From: "David Sean Taylor" [EMAIL PROTECTED] To: "JetSpeed" [EMAIL PROTECTED] Sent: Wednesday, February 07, 2001 21:21 Subject: RE: Secure Portlets Thomas, I was under the impression that a Portlet(Portal) API would define interfaces for all aspects of a portal container: services, the layout system, etc. From reading your comments, the scope of the Portlet API is now a little more clear. The quote below is from the PortletAPIRequirements doc, perhaps I am misunderstanding it: quote The Portlet API should allow for definition of service interfaces and for registration of services implementing particular service interfaces, e.g. User info (for getting user info like name, address, age...) Persistence (for storing per-user, per-portlet settings) Location (for obtaining the user's location) Personalization (for storing/getting personalization info) Data (access to databases, schema-to-object mappings) Content (access to syndicated content) Cache (access to URLs via caches) ... Rationale: This allows for a stable API core that can be extended by services as required. Portals implementing the Portlet API can provide implementations for a subset of the services defined in the Portlet API. /quote Generally, I think the services approach is futile in the Portal API, because the whole purpose of a well-defined API is that a portlet can run on any portlet container implementing that API. So we still need to define standard service interfaces, right? Its just not part of the 'Portlet' API. I am thinking that the Portlet API shields the portlet developer from these services, which are used internally in the portlet container. Take for example, Window Events. I assume they are some how connected to Window Managers (from Raphael's proposal), but the portlet doesn't use the WindowManager interfaces, it will instead handle window events. Are the components described in Raphael's proposal 'implementation only', or will they be a part of some 'standard' interface-api? Or, PortletData and DynamicData. (whats the difference?) Perhaps they are somehow persisting attributes using the PersistenceService. I still take comments and feedback. Is there no more interest in a new API or is everyone busy doing other things? No, there's a lot of interest. I know how that feels when you put a proposal out, and no one responses - and i hate that. My apologies. I will send more specific questions about the interfaces soon... - david -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Thomas F. Boehme Sent: Wednesday, February 07, 2001 4:21 AM To: JetSpeed Subject: Re: Secure Portlets Maybe I am missing something, but a portlet should not be concerned with things like a profiler service. Instead the profiler service determines which and how a portlet is called. Again, I may be missing something, but that's how I see it and that's why there isn't anything like that shining through in the API. A general service API has been left out of the most recent API because there needs to be more information on the type of services we are talking about. Generally, I think the services approach is futile in the Portal API, because the whole purpose of a well-defined API is that a portlet can run on any portlet container implementing that API. Services not known at compile-time seem to defeat that purpose. WRT, User and UserProfile -- that's a "bug" - it should be "User" only. An update will be posted soon (there are a few other things that were reported to me). I still take comments and feedback. Is there no more interest in a new API or is everyone busy doing other things? Thomas B. - O
Re: Secure Portlets
Santiago, Not a problem! Just write a SAXPortlet and a DOMPortlet (or even an ECSPortlet) and provide hooks to implement. I think we could/should supply them as part of the "abstract portlets that already do something useful for you" bucket. Cheers, Thomas B: - Original Message - From: Santiago Gala To: JetSpeed Sent: Thursday, February 08, 2001 3:29 Subject: Re: Secure Portlets Raphaël Luta wrote: [EMAIL PROTECTED]" type="cite">"Well-formed XML" simply implies that the output of the portlet will be parseable by an XML parser but does not enforce (or even expect) any DTD or schema compliance. My rationale for this is that I believe that, contrary to the servlet container which doesn't modify the servlet generated output, the portlet container will often want to adapt filter the produced content during the aggregation process (for example variable and link substituion in generated forms, markup stripping, output chunking, etc...). Even servlets, as of 2.3 spec, will have filters that can be chained, so that the request and response objects are wrapped and passed onto the next filter in the chain. So we have further case here.I think a consensus position could be to assume abstract subclasses (or subinteraces) in the API that could handle three kinds of request processing:- stream based, like servlets or jsp/velocity templates- SAX event based, for XSLT processing- tree based, like current ECS or DOMThe challenge would be to be able to mix the three classes of portlets in the same portal. For portals supporting the three types at the same time, I guess the MCM is stream, so the other classes would need to be serialized into the stream. For portals restricting to DOM and SAX, there are already tools to convert DOM to SAX to follow the chain of events.If you want to enforce XML, stream based portlets would need to be parsed and converted into SAX events or DOM trees. That could be, again, a basic utility in the toolkit.What do you think?-- -- To subscribe: [EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: List Help?: [EMAIL PROTECTED]
Re: Secure Portlets
Maybe I am missing something, but a portlet should not be concerned with things like a profiler service. Instead the profiler service determines which and how a portlet is called. Again, I may be missing something, but that's how I see it and that's why there isn't anything like that shining through in the API. A general service API has been left out of the most recent API because there needs to be more information on the type of services we are talking about. Generally, I think the services approach is futile in the Portal API, because the whole purpose of a well-defined API is that a portlet can run on any portlet container implementing that API. Services not known at compile-time seem to defeat that purpose. WRT, User and UserProfile -- that's a "bug" - it should be "User" only. An update will be posted soon (there are a few other things that were reported to me). I still take comments and feedback. Is there no more interest in a new API or is everyone busy doing other things? Thomas B. - Original Message - From: "David Sean Taylor" [EMAIL PROTECTED] To: "'JetSpeed'" [EMAIL PROTECTED] Sent: Tuesday, February 06, 2001 18:56 Subject: RE: Secure Portlets Chris, Yes, the profiler does support groups, but the security isn't implemented. So you could take the JetspeedProfilerService and extend with security. I will be doing just that, but first Im more concerned with how profiling services will work with the portlet api. I've seen that the portlet API has a User and ProfileUser object, but its not apparent if a 'profiling service' is even defined as a standard service. Thomas, could you explain how profiling services plug into the Portlet API? Sorry but its not apparent to me... Thanks, David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Kimpton,C (Chris) Sent: Tuesday, February 06, 2001 3:07 AM To: 'JetSpeed' Subject: Secure Portlets Hi, We want to make our portlet secure - so that only users in specific groups can access it. From the Jetspeed features, it seems like the profiler service should allow this - but I've not tracked down any more info on this yet. Any quick answers available on how this should be done - is a jetspeed.jcfg setting? Or a method needed in our Portlet? TIA, Chris == == This electronic message (email) and any attachments to it are subject to copyright and are sent for the personal attention of the addressee. Although you may be the named recipient, it may become apparent that this email and its contents are not intended for you and an addressing error has been made. This email may include information that is legally privileged and exempt from disclosure. If you have received this email in error, please advise us immediately and delete this email and any attachments from your computer system.Rabobank International is the trading name of Coperatieve Centrale Raiffeisen-Boerenleenbank B.A. which is incorporated in the Netherlands. Registered with the Registrar of Companies for England Wales No. BR002630 and regulated by the SFA for the conduct of investment business in the UK. The presence of this footnote also confirms that this email has been automatically checked by Rabobank International for the presence of computer viruses prior to it being sent, however, no guarantee is given or implied that this email is virus free upon delivery. -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED] -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED] -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: Secure Portlets
At 15:05 07/02/2001 +0100, you wrote: Raphael, 1- I still believe it's a bery bad idea not to impose a binding output contract between the portlet and the container - I'd like the API to only allow well-formed XML document output in order to make outpout post-processing as easy as possible (I thought last time we discussed this that the consensus was in implementing this restriction). There certainly wasn't consensus on the issue of an output contract. I am yet to see a convincing example of how such a contract should look like. A small example would be enough. Well-formed XML is *not* the answer to this particular problem. I am happy to repeat my 2 cents of reasoning for this: If the portal requires the portlet to adhere to a portal-set XML, then the portlet is severely limited as to what content it can display. This approach may well work for news-type content, but it is not general-purpose. You can't apply the same DTD to news, wheather, mail, calendar, to-do, stock, and you name it. If on the other hand, the portal asks the portlet to return well-formed XML according to a DTD that the portlet defines, it would also have to return a number of stylesheets for processing. But who is saying that a portlet that doesn't behave with raw markup, suddenly does so when providing a stylesheet? Apart from that, writing a stylesheet is more difficult than creating plain markup. The argument you are giving for the bloated interface kind of applies to this issue as well then. I think you're misreading what I wrote because of our last ApacheCon discussions ;) This has nothing to do with DTD and stylesheets. "Well-formed XML" simply implies that the output of the portlet will be parseable by an XML parser but does not enforce (or even expect) any DTD or schema compliance. My rationale for this is that I believe that, contrary to the servlet container which doesn't modify the servlet generated output, the portlet container will often want to adapt filter the produced content during the aggregation process (for example variable and link substituion in generated forms, markup stripping, output chunking, etc...). If the API enforces that the output will be parseable, this will dramatically reduce the occurence of run-time errors because developpers will need to take care of what they generate. If you consider our main target formats, they are all already XML based (WML, VoxML, SMIL, FO, etc...) except HTML, but producing XHTML instead of straight HTML is not too difficult and we can possibly provide some utility code that portlet writers can use in order to convert existing HTML to XHTML. Now I agree, that restricting output to markup langages may be restrictive since that means no binary or plain text output. I see these as fringe cases since it would be very difficult to aggregate these kinds data by any means (and it's certainly possible to handle these situations by using DTD/schema aware adapters at the layout engine level). -- Raphal Luta - [EMAIL PROTECTED] Vivendi Universal Networks - Services Manager / Paris -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
RE: Secure Portlets
Thomas, I was under the impression that a Portlet(Portal) API would define interfaces for all aspects of a portal container: services, the layout system, etc. From reading your comments, the scope of the Portlet API is now a little more clear. The quote below is from the PortletAPIRequirements doc, perhaps I am misunderstanding it: quote The Portlet API should allow for definition of service interfaces and for registration of services implementing particular service interfaces, e.g. User info (for getting user info like name, address, age...) Persistence (for storing per-user, per-portlet settings) Location (for obtaining the user's location) Personalization (for storing/getting personalization info) Data (access to databases, schema-to-object mappings) Content (access to syndicated content) Cache (access to URLs via caches) ... Rationale: This allows for a stable API core that can be extended by services as required. Portals implementing the Portlet API can provide implementations for a subset of the services defined in the Portlet API. /quote Generally, I think the services approach is futile in the Portal API, because the whole purpose of a well-defined API is that a portlet can run on any portlet container implementing that API. So we still need to define standard service interfaces, right? Its just not part of the 'Portlet' API. I am thinking that the Portlet API shields the portlet developer from these services, which are used internally in the portlet container. Take for example, Window Events. I assume they are some how connected to Window Managers (from Raphael's proposal), but the portlet doesn't use the WindowManager interfaces, it will instead handle window events. Are the components described in Raphael's proposal 'implementation only', or will they be a part of some 'standard' interface-api? Or, PortletData and DynamicData. (whats the difference?) Perhaps they are somehow persisting attributes using the PersistenceService. I still take comments and feedback. Is there no more interest in a new API or is everyone busy doing other things? No, there's a lot of interest. I know how that feels when you put a proposal out, and no one responses - and i hate that. My apologies. I will send more specific questions about the interfaces soon... - david -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Thomas F. Boehme Sent: Wednesday, February 07, 2001 4:21 AM To: JetSpeed Subject: Re: Secure Portlets Maybe I am missing something, but a portlet should not be concerned with things like a profiler service. Instead the profiler service determines which and how a portlet is called. Again, I may be missing something, but that's how I see it and that's why there isn't anything like that shining through in the API. A general service API has been left out of the most recent API because there needs to be more information on the type of services we are talking about. Generally, I think the services approach is futile in the Portal API, because the whole purpose of a well-defined API is that a portlet can run on any portlet container implementing that API. Services not known at compile-time seem to defeat that purpose. WRT, User and UserProfile -- that's a "bug" - it should be "User" only. An update will be posted soon (there are a few other things that were reported to me). I still take comments and feedback. Is there no more interest in a new API or is everyone busy doing other things? Thomas B. - Original Message - From: "David Sean Taylor" [EMAIL PROTECTED] To: "'JetSpeed'" [EMAIL PROTECTED] Sent: Tuesday, February 06, 2001 18:56 Subject: RE: Secure Portlets Chris, Yes, the profiler does support groups, but the security isn't implemented. So you could take the JetspeedProfilerService and extend with security. I will be doing just that, but first Im more concerned with how profiling services will work with the portlet api. I've seen that the portlet API has a User and ProfileUser object, but its not apparent if a 'profiling service' is even defined as a standard service. Thomas, could you explain how profiling services plug into the Portlet API? Sorry but its not apparent to me... Thanks, David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Kimpton,C (Chris) Sent: Tuesday, February 06, 2001 3:07 AM To: 'JetSpeed' Subject: Secure Portlets Hi, We want to make our portlet secure - so that only users in specific groups can access it. From the Jetspeed features, it seems like the profiler service should allow this - but I've not tracked down any more info on this yet. Any quick answers available on how this should be done - is a jetspeed.jcfg setting? Or a method
Re: Secure Portlets
Raphal Luta wrote: [EMAIL PROTECTED]">"Well-formed XML" simply implies that the output of the portlet will be parseable by an XML parser but does not enforce (or even expect) any DTD or schema compliance. My rationale for this is that I believe that, contrary to the servlet container which doesn't modify the servlet generated output, the portlet container will often want to adapt filter the produced content during the aggregation process (for example variable and link substituion in generated forms, markup stripping, output chunking, etc...). Even servlets, as of 2.3 spec, will have filters that can be chained, so that the request and response objects are wrapped and passed onto the next filter in the chain. So we have further case here. I think a consensus position could be to assume abstract subclasses (or subinteraces) in the API that could handle three kinds of request processing: - stream based, like servlets or jsp/velocity templates - SAX event based, for XSLT processing - tree based, like current ECS or DOM The challenge would be to be able to mix the three classes of portlets in the same portal. For portals supporting the three types at the same time, I guess the MCM is stream, so the other classes would need to be serialized into the stream. For portals restricting to DOM and SAX, there are already tools to convert DOM to SAX to follow the chain of events. If you want to enforce XML, stream based portlets would need to be parsed and converted into SAX events or DOM trees. That could be, again, a basic utility in the toolkit. What do you think? -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: List Help?: [EMAIL PROTECTED]
RE: Secure Portlets
Chris, Yes, the profiler does support groups, but the security isn't implemented. So you could take the JetspeedProfilerService and extend with security. I will be doing just that, but first Im more concerned with how profiling services will work with the portlet api. I've seen that the portlet API has a User and ProfileUser object, but its not apparent if a 'profiling service' is even defined as a standard service. Thomas, could you explain how profiling services plug into the Portlet API? Sorry but its not apparent to me... Thanks, David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Kimpton,C (Chris) Sent: Tuesday, February 06, 2001 3:07 AM To: 'JetSpeed' Subject: Secure Portlets Hi, We want to make our portlet secure - so that only users in specific groups can access it. From the Jetspeed features, it seems like the profiler service should allow this - but I've not tracked down any more info on this yet. Any quick answers available on how this should be done - is a jetspeed.jcfg setting? Or a method needed in our Portlet? TIA, Chris == == This electronic message (email) and any attachments to it are subject to copyright and are sent for the personal attention of the addressee. Although you may be the named recipient, it may become apparent that this email and its contents are not intended for you and an addressing error has been made. This email may include information that is legally privileged and exempt from disclosure. If you have received this email in error, please advise us immediately and delete this email and any attachments from your computer system.Rabobank International is the trading name of Coperatieve Centrale Raiffeisen-Boerenleenbank B.A. which is incorporated in the Netherlands. Registered with the Registrar of Companies for England Wales No. BR002630 and regulated by the SFA for the conduct of investment business in the UK. The presence of this footnote also confirms that this email has been automatically checked by Rabobank International for the presence of computer viruses prior to it being sent, however, no guarantee is given or implied that this email is virus free upon delivery. -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED] -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
