Re: [vote] Portlet API - Summary and IBM Position (long)
Steve, Suggestion: Add a configuration tag to the portlet definition which specifies whether or not the portlet will produce partial or full content. You probably mean the deployment descriptor, not the portlet definition... Suggestion: Create portlet wrappers for full content stripping so the containers won't have to deal with this stuff. That's exactly what the abstract classes (among other things) do in our latest proposal. Cheers, Thoma B. -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: [vote] Portlet API - Summary and IBM Position (long)
Steve, Can you give an example of how such a stub should look like? You may indeed have good ideas here... Cheers, Thomas B. - Original Message - From: "Steve Freeman" [EMAIL PROTECTED] To: "JetSpeed" [EMAIL PROTECTED] Sent: Sunday, February 18, 2001 21:32 Subject: Re: [vote] Portlet API - Summary and IBM Position (long) At 07:36 PM 2/18/2001 +0100, you wrote: 1.Primary output mode (This affects the programmatic Portlet API) Alternatives: a) output stream as base mode in portlet package sax as special mode in portlet.sax package b) neutral base interfaces in portlet package sax as special mode in portlet.sax package output stream as special mode in portlet.stream package c) sax as base mode in portlet package output stream as special mode in portlet.stream package Note: Whether or not portlets will run on all portlet containers does not depend on the primary output mode or the package structure of the API, but only on whether the specification defines all output modes as mandatory or not. When offering multiple output modes, the specification must mandate implementation of all of them by all portlet containers to assure portlet portability. Another alternative: Output in base portlet package as abstract stubs or an interface. Both SAX and Stream as child packages portlet.sax and portlet.stream, respectively. Set up the default mode using a properties file. This will allow a more natural subclassing of output functions which don't necessarily need to be based upon streams. Steve -- -- 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: [vote] Portlet API - Summary and IBM Position (long)
Thomas, Excuse me for not being fully up to snuff... At 10:25 AM 2/19/2001 +0100, you wrote: Steve, Suggestion: Add a configuration tag to the portlet definition which specifies whether or not the portlet will produce partial or full content. You probably mean the deployment descriptor, not the portlet definition... Yes. Suggestion: Create portlet wrappers for full content stripping so the containers won't have to deal with this stuff. That's exactly what the abstract classes (among other things) do in our latest proposal. Great! I suppose I should go read the proposal, eh? ;) This should speed up the parallel processing on an SMP machine, provided that portlets on a page are processed on separate threads. Steve -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: [vote] Portlet API - Summary and IBM Position (long)
Thomas, I'll try to do this without having all of the details clear in my head. First, there's the package hierarchy: portlet portlet.stream portlet.sax In the portlet package, there should be an interface to define the contractual requirements of the child package methods. We could call this PortletOutputInterface, or some such. It would need to define a method for setting up the output stream to be used by the child package: setupOutput(stream) The portlet package would define the default implementation, implementing the interface. This should be an abstract class. The classes in the child packages need to subclass the abstract class or the interface. The abstract class might then have a method called setupOutput() which would look up the name of the method to invoke in order to dump the output to the actual output stream (which is really the end result, no?). The method name would be placed into a property somewhere (details tbd). setupOutput() would then call the named method with a parameter of the actual output stream. The method would be responsible for connecting the back-end data source to the output stream. portlet.stream would then write directly to the output stream. This would be called directly from the portlet. portlet.sax would have to complete the parsing of the DOM tree before walking the tree, possibly transcoding it into another format, and finally sending it to the output stream. This class would implement the necessary callback hooks between it and the portlet to enable the parsing and event handling required to convert the input source into a valid output stream. That's my thinking, anyway, which is subject to change at this point. I've got to do some digging into the existing packages to see what's being done for the portlets before I can go any deeper on a possible implemenation. Give me a day or two. BTW, I'm working on the IBM Portal too.. with the Raleigh folks. I'll send you an internal note so you'll have my address. Steve At 10:21 AM 2/19/2001 +0100, you wrote: Steve, Can you give an example of how such a stub should look like? You may indeed have good ideas here... Cheers, Thomas B. - Original Message - From: "Steve Freeman" [EMAIL PROTECTED] To: "JetSpeed" [EMAIL PROTECTED] Sent: Sunday, February 18, 2001 21:32 Subject: Re: [vote] Portlet API - Summary and IBM Position (long) At 07:36 PM 2/18/2001 +0100, you wrote: 1.Primary output mode (This affects the programmatic Portlet API) Alternatives: a) output stream as base mode in portlet package sax as special mode in portlet.sax package b) neutral base interfaces in portlet package sax as special mode in portlet.sax package output stream as special mode in portlet.stream package c) sax as base mode in portlet package output stream as special mode in portlet.stream package Note: Whether or not portlets will run on all portlet containers does not depend on the primary output mode or the package structure of the API, but only on whether the specification defines all output modes as mandatory or not. When offering multiple output modes, the specification must mandate implementation of all of them by all portlet containers to assure portlet portability. Another alternative: Output in base portlet package as abstract stubs or an interface. Both SAX and Stream as child packages portlet.sax and portlet.stream, respectively. Set up the default mode using a properties file. This will allow a more natural subclassing of output functions which don't necessarily need to be based upon streams. Steve -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: [vote] Portlet API - Summary and IBM Position (long)
After the discussions we had during the last few days and before the upcoming decision, I'd like to provide a new summary of the current state of the discussion and explain IBM's position in a separate section at the end, after the dotted line. We are all in agreement about our common goal :) - Raphael has provided an excellent description of this goal: "The Jetspeed community has decided to start specifying a Portlet API that could be proposed as a standard for all portal implementations. Offering a standard API between portals only makes sense if the portals implementing the API can guarantee to the portlet writers complying to this API that their portlet will always run correctly whatever the implementation they are deployed upon: 'write once, deploy anywhere' This is the reason why the Portlet API should define both the programmatic API as such, but also the content guidelines that portlet writers should follow to achieve portability and possibly the deployment process." There are open questions on how to realize this goal. I'd like to ask everybody to spend an appropriate amount of time to think through all the implications of all different alternatives before we decide, including relation to the Servlet API and XML APIs, acceptance of the Portlet API by portal product vendors, induced development costs for portal vendors, system complexity, performance and scalability, etc. Three orthogonal issues (1-3) need a decision, after that, we have to choose from several implementation options (4). 1.Primary output mode (This affects the programmatic Portlet API) Alternatives: a) output stream as base mode in portlet package sax as special mode in portlet.sax package b) neutral base interfaces in portlet package sax as special mode in portlet.sax package output stream as special mode in portlet.stream package c) sax as base mode in portlet package output stream as special mode in portlet.stream package Note: Whether or not portlets will run on all portlet containers does not depend on the primary output mode or the package structure of the API, but only on whether the specification defines all output modes as mandatory or not. When offering multiple output modes, the specification must mandate implementation of all of them by all portlet containers to assure portlet portability. 2.Fragments and/or Full Documents (This affects portlet container performance and ease of implementation - and thus development costs) Alternatives: a) only document fragments concatenatable without post-processing - high-performance - low effort implementation of portlet container - requires to strip off tags from tool-generated document templates once in advance - container can easily concatenate portlet output - container can be agnostic to fragments' internal structures b) document fragments and full documents - high performance possible if programmers use fragments - higher effort for implementation of portlet containers - container must strip off tags from full documents generated by some portlets at run-time and be able to handle framents. - container must be aware of document structure and know what parts have to be stripped off for each particular markup type c) only full documents that require post processing - lower performance - higher effort for implementation of portlet containers - container must strip off tags from documents generated by portlets at run-time - container must be aware of document structure and know what parts have to be stripped off for each particular markup type 3.Internal structure of documents of fragments a) only potential contents of tables, cards, etc., i.e. fragments could not contain multiple cards or pages - simple aggregation b) potential content of tables, multiple cards, etc., i.e. fragments could contain multiple cards or pages or card content - aggregation must be able to handle multiple cards/pages returned by portlets 4. Implementation options a) Streams/Fragments only Simple, high-performance, highly scalable implementation In advance Runtime Runtimeor on-the-fly ++ --- +-+ ++ || | Portlet |-Fragent--||-Doc || --- +-+ Template || Template || --- +-+ || || | Portlet |-Fragent--||-Doc | Portal | --- +-+ Template |Frag| Template | Aggre | --- +-+ |Tool| | gation | | Portlet |-Fragent--||-Doc || --- +-+ Template || Template || --- +-+ || || | Portlet |-Fragent--||-Doc ++ ---
Re: [vote] Portlet API - Summary and IBM Position (long)
Thomas Schaeck wrote: Unlike the Servlet API, the Portlet API would additionaly provide explicit SAX support in the sax package and introduce a dependency on org.xml.sax, i.e. a separate package. Such a dependency of an API package to another API package that is not part of the core Java classes is rather uncommon. FYI - SAX is provided by JSR 5 (aka, JAXP). Sources tell me that JAXP will be included in JDK 1.4. - Sam Ruby -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: [vote] Portlet API - Summary and IBM Position (long)
Sam Ruby wrote: Thomas Schaeck wrote: Unlike the Servlet API, the Portlet API would additionaly provide explicit SAX support in the sax package and introduce a dependency on org.xml.sax, i.e. a separate package. Such a dependency of an API package to another API package that is not part of the core Java classes is rather uncommon. FYI - SAX is provided by JSR 5 (aka, JAXP). Sources tell me that JAXP will be included in JDK 1.4. - Sam Ruby Cool! I knew about JAXP, but so far I only heard statements that the XML APIs *may* be included in JDK 1.4. The *will* sounds much better. That should resolve the issue. Best regards, Thomas Thomas Schaeck Portal Architect IBM Pervasive Computing Division Phone: +49-(0)7031-16-3479 Mobile: +49-(0)171-6928407 e-mail: [EMAIL PROTECTED] Fax: +49-(0)7031-16-4888 Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen, Germany -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
Re: [vote] Portlet API - Summary and IBM Position (long)
At 07:36 PM 2/18/2001 +0100, you wrote: 2.Fragments and/or Full Documents (This affects portlet container performance and ease of implementation - and thus development costs) Alternatives: a) only document fragments concatenatable without post-processing - high-performance - low effort implementation of portlet container - requires to strip off tags from tool-generated document templates once in advance - container can easily concatenate portlet output - container can be agnostic to fragments' internal structures b) document fragments and full documents - high performance possible if programmers use fragments - higher effort for implementation of portlet containers - container must strip off tags from full documents generated by some portlets at run-time and be able to handle framents. - container must be aware of document structure and know what parts have to be stripped off for each particular markup type c) only full documents that require post processing - lower performance - higher effort for implementation of portlet containers - container must strip off tags from documents generated by portlets at run-time - container must be aware of document structure and know what parts have to be stripped off for each particular markup type Suggestion: Add a configuration tag to the portlet definition which specifies whether or not the portlet will produce partial or full content. Suggestion: Create portlet wrappers for full content stripping so the containers won't have to deal with this stuff. Steve -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
