portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Sean Taylor <da...@bluesunrise.com>
Subject Re: Page Aggregation Design
Date Thu, 27 Nov 2003 00:34:37 GMT

On Wednesday, November 26, 2003, at 01:16  PM, Barnhill William wrote:

> I've had a chance now to go over the sources more, and read the docs, 
> including docs/PageAggregationDesign.txt.
> It sounds good,

moving on (whizzzz)

>  but what do you think of the idea of using a single 
> request/response-attribute (layout-description) to gather layout 
> information using the LAYOUT mode, and storing that info as a dom 
> instance in that attribute?
The recursive tree of layout has to be stored in some kind of model.
The proposal suggests a fragment model made up of portlets which stream 
their content using the Portlet API interfaces.
Im not sure what the DOM gains us since I think we can have more 
control over the caching of portlets using a fragment model.
The fragment tree can be stored in the database, along with an XML file.

This has been argued numerous times on this list going way back.
Check the list going back 2 years when IBM was active on he Jetspeed 
list under subjects such as
Streaming vs DOM-based aggregation.
I think you will see that most portal vendors, and the portlet API are 
However this shouldn't stop us from implementing a DOM-based solution, 
for good reasons.

> Each layout portlet would construct its own node tree and pass it back 
> in the response attribute layout-description.  The value passed back 
> would be inserted into the parent's node tree, which would then be 
> passed back up in the same manner.
Please take a look at Cocoon's portal. It works very much like your 
description above.

Also review the Portlet spec, sections 12.3 RenderResponse interface, 
12.32 output streams, 12.3.3 buffering

> <portlet peid="yutu" type="layout">
>    <portlet peid="eere" type="content">
>          <renderHints>
>                <hint name="xxx" value="yyy" />
>          </renderHints>
>    </portlet>
>    <portlet peid="sdsd" type="layout">
>        <portlet peid="sss" type="content">
>              <renderHints>
>                    <hint name="xxx" value="yyy" />
>              </renderHints>
>        </portlet>
>    </portlet>
> </portlet>
> You will have more performance overhead, but it seems more extensible 
> and you can pass more information back.
> If this was applied to remote portlets you would also have bandwidth 
> issues, but these might be brought within acceptable levels using 
> compression perhaps with binary representation of the XML, similar to 

> I'll be the first to admit that the performance drawbacks of the above 
> approach may outweight the extensibility benefits. Ideally two 
> implmentations of  LayoutValve interface could be created and a 
> standard default implementation could be chosen.  If someone wants the 
> features in the other implementation then they could unplug the one 
> and plug in the other.
Sounds good if we can get the model to plug into a DOM aggregator it 
may be worth while

> I'm not very versed in participating in open source projects, 
> especially not at earlier stages, but would a LayoutValve requirements 
> spec, a Layout portlet spec, and a set of JUnit compatibility tests be 
> appropriate? Or is that too formal?
> Please be patient while I learn how to play in the bazaar ,
> Bill Barnhill

You seem very well versed in the software development process.
I am sure you have worked on projects for companies and interacted with 
other developers.
This is really not any different, with the exception that everything is 
done in public, out in the open.
We just ask that you are considerate of others needs and always design 
for the best of the project and community and not your immediate needs. 
Oh and one other thing, we have this concept called "democracy" -- all 
the committers vote on big decisions. We don't have managers, at least 
not here we don't.

Regarding Performance it reminds me that we are challenged to make a 
better portal engine than our previous efforts

David Sean Taylor
Bluesunrise Software
+01 707 773-4646
+01 707 529 9194
+44 (0)79 8538 6471

To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org

View raw message