Hi, enclosed is a log of the portlet API chat on Wednesday evening. Raphael wanted to post it, however I haven't seen any message from him since - he's probably very busy. I think the most imporant part is at the bottom: <raphael> OK. So what we have said tonight is : <raphael> - portlets should be as portable as possible but limited portability may be imposed by incompatible content models <raphael> - fragments are the prefered output model for portlets but portal must implement full documents support as the default <raphael> the content model used by a portlet is defined in its portlet descriptor <raphael> - the API will have streams in the base response API, SAX support in a sub-interface <raphael> - compliant portals must implement both interfaces I "updated" the API propsal java docs, i.e. "reverted" it to the second last version... I promised Raphael, to update the java doc to reflect the results of the chat, however I have the problem that most of these points have to go into a portlet _specification_ rather than in the API... --> We need to develop a spec. So into the spec had to go: * compliant portals must implement both interfaces, stream and SAX * fragments are the prefered output model for portlets but portal must implement full documents support as the default the content model used by a portlet is defined in its portlet descriptor Sorry I'm in a hurry, hope I didn't forget anything important. ingo. Chat.log ============================================================================ Session Start: Wed Feb 21 20:14:41 2001 * Logging #jetspeed to 'logs\#jetspeed.log' <ingo> thomas? <raphael> not there yet apparently :) <ingo> ok, which thomas is it? ;-) <raphael> any will do <ingo> sure, I was just wondering which thomas "blob_79" is... But he doesn't seem to listen right now. <raphael> he tried a ping some time ago but has not said anything yet *** sgala has joined #jetspeed <sgala> hi *** AlexLi has joined #Jetspeed <raphael> hi santiago <sgala> hi, I'm here with Juan Carlos, out in Ciudad Real, in a internet gaming place... :-) <ingo> Hi Santiago, Hi Alexandra. <AlexLi> Hi all <raphael> thomas is here ? <blob_79> yes! <sgala> Hi, thomas. <raphael> which thomas are you ? <raphael> :) <raphael> it seems like most interested parties are there, so maybe we shall start <blob_79> I subcribed jetspeed mailing list and was just a bit interested in your chat. <ingo> Yes, if david is listening as well? <david> yes, im here <raphael> ON I'll try to be the moderator for this <ingo> None of the "IBM Thomases" seems to be here, but we can start anyway. <sgala> GO slowly, we have a big lag... <raphael> I guess all the people here have read the portlet API proposals <raphael> but before starting the real discussions maybe ingo and I can answer any <raphael> outstanding questions on our respective APIs <ingo> sure. <raphael> ANy questions ? <raphael> Great, this will go quickly... :) <raphael> I think the first discussion point should be: <raphael> is it a goal of the portlet API to allow the writing of portlet components <raphael> that are fully portable on *all* compliant portal, or is it enough to guarantee <raphael> portability on a subset of compliants portal ? <raphael> My position is: <raphael> I'd *really* like fully portable components but it has a lot of <raphael> performance impact, so in order to achieve compromise I can live with partial <raphael> portability <ingo> I would like full portability as well. <ingo> However, I think apart from performance, there is also the aspect that <ingo> the portlet API should be clean enough to serve as a basis for a standard. <ingo> If we'd came up with a lot of different portlet types, <ingo> that all have to be supported by every container developer, <ingo> we might scare people off. Especially if support for all types is <ingo> integrated into the "base interface" so that it get's too overloaded. <ingo> If we find an elegant way for full portability, great. I could even live <ingo> with the fact that some containers had a bad performance for _some_ portlet types, <ingo> but if we risk that noone wants to pick up our API, then I'd better drop full portability. <ingo> <end> :) <raphael> david ? *** bjoern has joined #jetspeed <david> we are really talking about two portlet types, <david> streams and sax events <david> is that asking too much from container providers? <raphael> santiago ? <ingo> no, I don't think so. However the subinterfaces invite to define more types. <sgala> I would like to have portlets that deliver content and interaction information, <sgala> independent of any given markup. <sgala> We have to deliver a VoiceML demo briefly, and I would hate having to <sgala> maintain getHTMLContent(), getWMLContent(), getVoiceMLContent() getIE4.01Content() :) <raphael> you're not answering the question... ;/ <sgala> So, I think the portlet should stay at a "knowledge" level, be it bean based or markup based. <sgala> A knowledge level guarantees, if properly standardized, that any portlet will run on any container. <sgala> Each container should be responsible of translating this "knowledge" to device markup. <raphael> But such a scheme has very broad implementations implications that will <raphael> reduce acceptance and you also limit legacy information retrieval and display like <raphael> the WebPagePortlet. This is a need that IMO we need to cater for. <raphael> I tink "pure knowledge" portlets as very valuable but hardly as the appropriate <ingo> sorry, what _exactly do you mean by "knowledge level"? <raphael> response for all the portal needs unless you don't have any IT infrastructure to <raphael> reuse in your portal... <end> <sgala> I mean abstract, not device related markup, or attribute-value pairs. So I said "bean based", <sgala> because it could be a "turbine toolbox" object, or something that provides information. <sgala> BUt I agree this is a long term goal.<end> <raphael> From all the comments, I gather that we all agree that limited portability is an <raphael> appropriate immediate goal for the Portlet API. Right ? <ingo> Well, <sgala> For the short term, I think SAX + stream is a good compromise, since it enables both processings. <ingo> if we have only the SAX and stream, I could imagine mandatory suport for both. <ingo> At least from our point of view, <ingo> having stream as _the_ way, it is not too hard to add a (simple) support for SAX portlets. <sgala> Rapheal, what do you mean by limited portability? <ingo> Don't know if it's as easy the other way round? <raphael> santiago > limited portability = some containers may not run some portlets either because <raphael> they don't support the correct output mode or because they don't support the <raphael> same output content model <raphael> ingo > stream -> SAX is very easy if we can rely on well-formedness of content, it just <raphael> means parsing the stream <end> <ingo> so then, <ingo> I could live with partial support, but we could also mandate SAX and stream support for portlet API 1.0. <raphael> portability will be defined by output mode + content model not simply output mode, in fact <raphael> I think content model is more important than output mode for portability, <ingo> true, the content model makes more problems. You're right, <raphael> output mode is determinant for performance <ingo> partial support is probably better for the start. <ingo> sorry for interrupting. <raphael> no worries :) <raphael> Every agrees on partial portability ? (just +1/+0/-1) <sgala> +1 <ingo> +1 <raphael> +1 <david> uh, sorry, could you explain the content model a little more... then I will vote <raphael> content model = what the portal expect the portlet to output: <raphael> - full documents <raphael> - specific doc fragments <raphael> - "knowledge" but no layout markups, etc... <end> <david> ok - so we are saying that a container is not required to impl. both full and fragments. Thats what you mean by partial portability? <raphael> basically yes -> [AlexLi] PING <david> +1 <raphael> That's settled then. <raphael> Point 2: <raphael> Content model: which content model should we allow/mandate ? and how ? <raphael> My position: <raphael> Default requirement: when no more specific recommandation exists, the portal <raphael> should expect the portlet to output complete documents (default mode).. <raphael> Mandate that all portal support at least HTML "table-fragment" model <raphael> Defined some formalized WML content model but don't mandate implementation <raphael> Use the portlet deployment descriptor to specify the portlet content models <raphael> and allow the portal to use the "best" available according to its implementation <end> <ingo> So, <ingo> you would also mandate support for full documents. <ingo> What about other markup? <ingo> <end> <raphael> I don't know all the markups... :) I guess we can define some normalized <raphael> fragment content models for some, but I don't see how to support new markups <raphael> without the "full valid docs" as the default rule <end> <ingo> Ok, <ingo> I don't _really_ like full documents as default, but I can see that this <ingo> is the most sensible default setting. I couldn't live with full documents only, <ingo> but both defined by the deployment descriptor <ingo> seems as a good compromise. Obviously I'd prefer (good) fragment definitions <ingo> as default more. <end> <raphael> santiago ? <sgala> I see your point here, Raphaël. With abstract XML markup there would need to be a heavy specification effort also to specify THE abstract markup(s).<end> <raphael> david ? <david> does there have to be a 'default', since the defaultmode can be defined in the descriptor? <raphael> the descriptor will allow the portlet to specify which fragment/model it <raphael> supports but if santiago writes a portlet outputting GALAML, he probably <raphael> won't wait that someone define a common acceptable fragment content model, <raphael> so we need to have a "default" rule when no fragment model is defined... <ingo> On more point, <raphael> In fact, I would expect most portal implementations to focus on handling their <raphael> chosen fragment models, and then retrofit the "full document" requirement with <raphael> an output stripping module thet convert the "full doc" -> appropriate fragment... <ingo> Are you sure, that full documents are really easier to support? Wouldn't the portlet container <raphael> On most implementations, "full docs" portlets will perform less efficiently than their <raphael> fragment counterparts, but it's quite difficult to specify general enough <raphael> fragment specification in some markups like WML (and I expect VoiceML, etc...) <end> <sgala> Also, the point you made about "new" markups having to wait until someone agrees on a fragment model.<end> <ingo> need to have similar rules for defining fragments? So even with full document support, you <ingo> need to define fragment rules first before you can actually start <ingo> to support a portlet. This in mind I'd withdraw my statement about <ingo> "most sensible", instead it's the easiest way for the portlet API spec. Still, <ingo> the work of defining fragment rules has to be done in both cases. <end> <raphael> ingo > yes, the portal will need to have a fragment model to work with, but <sgala> 4[12ingo4] 1> The difference is that the rules are defined by the siteadmin, and a portlet provider can sell a portlet without too much customisation.<end> <raphael> starting with "full docs", the fragment model may be portal specific and not a <raphael> consensus model <end> <ingo> ok, <ingo> you mean that the portal container can decide whether several cards are allowed <ingo> as output of one portlet or not. But what do you do if you decide not to support several <ingo> card per portlet and get a full wml document contaioning several cards? You won't have such problems <ingo> with fragment rules specified by the spec. <end> <raphael> if you don't support multiple cards -> you expect the content to fit a single card, <raphael> so if the portlet output several cards, you have some implementation decisions to <raphael> make (like building a "summary" card that links the full portlet generated <raphael> deck output by the portlet) <end> <ingo> won't this spoil <ingo> portability in some way too? - The same portlet would have a different appearance <ingo> on different portal implementations. <end> <raphael> do you consider that appearance should be portable and preserve across portal ? <ingo> no, right that must be left to the portal. <ingo> What about the postprocessing? <raphael> Yes ? <ingo> WOn't it become much more complicated with full documents? Imagine <ingo> the event mechanism, it'd much easier if every portal asks the container for <ingo> a UID to prefix it's "triggers" instead of parsing through the full document. <end> *** bjoern has quit IRC <raphael> If you mean that link management should be directly handled by the portlet through <raphael> an API call wether its output is full or fragments, I'd say yes. <ingo> ok. <raphael> I see some issues with the "event model" proposed in the current API <raphael> (because you use object instances in the method), but let's leave this point for <raphael> today :) <end> <ingo> still, doesn't the "full document requirement" <ingo> just shift the porblems of defining fragment rules to the portlet container? And <ingo> won't it probably easier if the portlet writer already made sure that those rules <ingo> are taken into account instead of letting the portal container check and enforce it? <ingo> <end> <sgala> Raphaël > I have to read more deeply the event mode. I would leave the event model for other discussion :) <raphael> ingo > can you propose something else that doesn't require us to analyze <raphael> all the markups that a portlet may want to output and define a recommended <raphael> fragment content model ? <ingo> well, don't we have <ingo> to do this anyway (as we are implementing a portlet container)? We could <ingo> start with rules for WML and HTML and make new revisions of the spec for new markups. <ingo> <end> <sgala> I see you point :-? <raphael> We don't have to claim that our content model is appropriate for all purposes and <ingo> I mean, <raphael> implementation. I expect that the definition of a well-accepted fragment model <raphael> will be a difficult task in many markup cases. Fortunately, HTML is easy so whatever <raphael> HTML fragment we support will probably be sensible for other portals too. <e> <ingo> What about fragments and portability? <ingo> If we want to <ingo> have portlets portable that only output fragments, there has to be a specification <ingo> of fragment rules in the spec again. <e> <raphael> +1. Except that I'd like to leave the "winner" content model to the portlet <raphael> writers : imagine that we first specify WML and HTML fragments and that we <raphael> only supports them in our implementation... <raphael> 2 other companies decide to extend our base implementation and add SMIL support <sgala> [Note. We have little time left here] <raphael> , each will support an implementation specific SMIL portlet model since no one <raphael> is dfined yet and will push for acceptance as the base fragement model for <raphael> SMIL <raphael> ... -> definition of consensus may be hard to achieve... <raphael> My position: let's define as good fragments specs as possible as recommended, <raphael> provide a fallback doument model (full documents) that can be used whenever no <raphael> formal spec is defined and let the portal implementors/portlet writers chose <raphael> which is the best (if all portlets support 1 specific fragment content, it's *** jason has quit IRC (EOF From client) <raphael> proabbly pretty good...) <e> <ingo> But then, <ingo> you'd require every portlet to be able to output full documents... <sgala> [THey close this shop :(] <sgala> Q: is there any voting left? <raphael> Yes <ingo> Can you get somewhere else soon? <sgala> Raphaël>Could you send me the complete log by email tomorrow. please? <raphael> Vote: do we support my previous proposed scheme ? (+1/+0/-0/-1) <raphael> santiago > Ok for the logs, can you vote please ? <sgala> Default --> full doc, agreements for specific models, election at portal ? <ingo> wait, this is a bit fast. Do you require all portlets to be able to output full documents? <sgala> Then +0. I need to go. <raphael> not portlets but portals must accept full docs <raphael> bye santiago *** jason has joined #jetspeed <ingo> Then a portlet that wants to be portable needs to be able to output full documents? <raphael> no, not if a recommended fragment model exists, as it is the case for HTML at least <raphael> full documents should be the fallback because there are costs associated with <raphael> its support.<e> *** sgala has quit IRC (8,1 IR0cap 046.999 14,14 1,10 9 14,14!15,15!) <ingo> [that's a pity!] <raphael> david , what's your opinion on this ? <ingo> so, if fragments are recommended, a portlet should deliver them, <ingo> if there aren't any, full documents are the fallback? <david> again, i was trying to be diplomatic and say that the default fallback is configurable in a 'container' deployment descriptor, <david> my opinion is that both should be supported, but i can see where ibm would want the default fallback to be fragment... <raphael> not exactly: if for a given markup, their is a recommended fragment definition, then <raphael> a portlet can safely implement a fragment model only and be portable across all <raphael> portals implementing this model (hopefully all) but it can also chose to always <raphael> output full documents and be guaranteed to be portable (at the cost of runtime <raphael> performance) since a portal would have to also accept full documents. <e> <ingo> but where is the point of outputting full documents, <ingo> if there is a recommended fragment rule that is guranteed to work with all containers?... <raphael> write a simple portlet wrapper around an existing application ? <ingo> Shouldn't - if rules can be found and are defined - they be mandatory? <ingo> Yes <raphael> mandatory for portals yes, for portlet I don't think so. <ingo> you wold be able to write a simple wrapper, <ingo> not having to deal with "stripping" the output, but the container had to do it anyway, <ingo> just one processing step later. <e> <raphael> so basically we chose whether the portlet writer or portal implementor has to work more... <raphael> I believe that in general portal implementors will be smarter and more skilled that <ingo> well, there could be a base class provided for such tasks. <raphael> portlet writers, so making the job simple for portlet writer makes sense to me <e> <raphael> your base class would probably be optimized for a given portal implementation *** blob_79 has quit IRC (Ping timeout) <raphael> model (SAX, stream...) <e> <ingo> Well, we could have base classes for both - optimized. <ingo> A compromise: *** dst has joined #jetspeed *** david has quit IRC (Connection reset by peer) <ingo> We allow portlets to deliver full documents, but *strongly* point out in the specs, <ingo> that this should only be used for cases like wrapping legacy applications and <ingo> that there might be a significant perfomance impact. <e> <raphael> +1 for insisting on the performance impact and prefering the fragment model when it <raphael> exists, -1 for specifying that it "should" be used only for something as <raphael> we can't know all the possible use <e> <raphael> alexandra, do you have something to say ? You're from IBM too, aren't you ? <ingo> I'd be still +1 for "should", but +0 for the first part. So "prefering" could probably agreed upon. <raphael> :) <raphael> david, is this something you can agree upon too ? <ingo> she has her child "jumping around", so she might not listen all the time. :) <dst> im here to agree on things <dst> id like to see this move forward :) <AlexLi> I am listening now. I mean, Ingo already brought all the arguments we discussed together by IBM, <AlexLi> so nothing to add , actually. <raphael> disagreement is sometimes good because it makes you think about the over POV around... <ingo> POV? <dst> pointof view <raphael> I rather enjoyed the disussions and I think I have a clearer picture of where <raphael> we're going <e> <raphael> Anyway, from the discussion, I gather that we are all at least +0 on this subject ? <raphael> alex > I'm lucky I'm working late then... I don't have to look after my child ;/ <ingo> Well, I don't like the idea of having to support full html documents, but so it be :-/ <ingo> (-0 probably expresses it better) <AlexLi> I am also actually +1 on fragments, but I think it is really important to have a compromise that <AlexLi> is acceptable for all of us. <raphael> OK. <raphael> Point 3: Output methods: default SAX / default Stream / no default and subclasses <raphael> My position: <raphael> The default SAX really make sense only if we are in a always "full docs" content <raphael> model as its main use is to facilitate post-processing. Since we are not in <raphael> this case, I accept any of the 2 alternatives with a preference for a <raphael> symmetric API (provided it doesn't look too silly) <e> <ingo> This seems to be an easy one then. I'm +1 for stream as default. ;-) <raphael> I think Santiago would be the strongest proponent of the SAX model because it fits <AlexLi> As you can already imagine, I am also +1 for stream default and +0 on no default <raphael> his current portal model... it's a pity he's not there anymore :( <ingo> well, to be fair, we musn't finish voting now. <ingo> What if we vote now and leave the others tomorrow? <raphael> No, all the votes cast here are just for making progress toward an agreement <raphael> the mailing-list is the real voting ground since some committers who have votes <raphael> are not here and voting must not be a synchronous process to account for the <raphael> wide diversity in the community. <ingo> ok, that fair, actually the way it has to be. <raphael> The goal of this chat is mainly to avoid the portlet API thread from respawning <raphael> a 3 weeks discussion... :-) <dst> ok, ive got to run. are we going to cover anything else? <raphael> output model > I'm +1 for stream only if the SAX (either as a base interface or <raphael> sub-interface must be implemented by all containers -> ensure that SAX based <raphael> portlets are as portable as stream based) <e> <ingo> that's ok with me. <raphael> david > we just need your opinion on the output mode and we're pretty done <dst> +1 - it makes sense to have stream in the base, and sax as an adapter or subclass <dst> +1 on having stream implemented by all <raphael> OK. So what we have said tonight is : <raphael> - portlets should be as portable as possible but limited portability may be imposed by incompatible content models <raphael> - fragments are the prefered output model for portlets but portal must implement full documents support as the default <raphael> the content model used by a portlet is defined in its portlet descriptor <raphael> - the API will have streams in the base response API, SAX support in a sub-interface <raphael> - compliant portals must implement both interfaces <raphael> Is that correct ? <ingo> yes, I think that's what most people agreed too. <dst> yes <AlexLi> yes <raphael> good. I'll post the IRC logs on a website so that people who were not <raphael> part of the discussions can read it. <ingo> One last point, please! <raphael> go ahead, but quickly, I've not had my lunch yet... <ingo> I still don't like the idea of supporting full html documents. Can't we probably find <ingo> three levels of fragment rules: <ingo> none (=full documents), recommendations and mandatory?... <ingo> for WML we can probably only find a recommendation, but in cases like html, <ingo> it may be possible to find rules that are easily acceptable to everybody? <raphael> yes, that's what I proposed in the beginning : manadatory support for at least "full docs" and HTML "table-fragment model" :) <ingo> still the "full docs". I see, I'll have to live with it... <raphael> ;) ingo > can you modify the proposed API to reflect this ? <ingo> [ok, raphael, perhaps you can find an example for when full html docs make much sense (apart from the wrapper)?] <ingo> Yes I modify it. <dst> bye :) *** dst has left #jetspeed (dst) <ingo> ok, I think we've made a good step forward. <raphael> ingo > for example if the portal can collect all the <meta> tags of a portlet <raphael> output and use them as <meta> for the complete page -> very search engine friendly. <ingo> interresing thought, have to think about it. <raphael> I can't really think of something better right now but it's late, I'm hungry and I want <raphael> to finish my new velocity customizer implementation :) <ingo> well, the API could support this as well. But I think we should come to an end, right. <raphael> thanks for the chat, maybe we'll do another session soon ? <ingo> Thank you Jon and Jason for staying with us! <ingo> Yes, I think this is a good way for discussing "hot topics", definitely. <ingo> Well then, let's part. I'm hungry as well :) Session Close: Wed Feb 21 22:55:11 2001 -- -------------------------------------------------------------- To subscribe: [EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: <http://www.mail-archive.com/jetspeed@list.working-dogs.com/> List Help?: [EMAIL PROTECTED]
