[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [wsrp][interfaces] 4/25 meeting summary
Last weeks agenda and results were: Agenda: a) complete last weeks discussion of which operations in the Portal Usage document we should work on in the first version of the specification. I believe we just need to discuss the Portlet Service Disabled state and Portlet Service upgraded state. Meeting Summary: Disabled State: We decided to defer discussing/specifying the transitions from enabled to disabled states and vice versa. There is some question whether this effects the protocol at all as one could build a system where either the producer/consumer arbitrarily goes into this state and the opposed component must discover or intuit this state from its inaccessibility. Even if there would be an impact on the protocol it was decided it would be a secondary issue best pushed into a later version of the specification. Upgraded state: We decided this issue should be addressed/covered in the specification. b) begin discussing (by answering questions) portlet service registration. The questions to be answered/discussed were sent out yesterday. Meeting Summary: We started discussing (by answering posted questions) topics related to State 0: Service Unknown and State 1: service becomes known. State 0: Portlet Service Unknown We identified that the question relating to how a portal locates a service belongs in this state vs. where it was originally placed in State 1. We decided that the specification will not mandate how a portal locates a service. We decided that the WSRP group will provide a "best practices" document (maybe as an addendum to the spec) that details how UDDI can be used. We decided that the address of a Portlet Service (for purposes of binding to it) is the URL to the WSDL service description. State 1: Portlet Service is activated 1) We discussed the scope of a portlet service. We decided that a portlet service is a container of portlets not a portlet itself. We decided that the portlets it contains are not services but rather logical entities that are interacted with through the container (portlet service). This leads to the requirement that a portlet can be identified/targeted within a container. We did not (as of yet) discuss how a portlet is identified. 2) Discussed the set of services/function a portlet service expects a consumer to (be capable) of providing it. To the list I originally provided we added: URL rewriting, Authentication, Identity/Profile information, and View context. Rather then discuss how these impact the protocol in detail we decided to move on and address them as they came up in the natural flow of discussions. 3) Had very preliminary discussion of what a portal/portlet service must be able to accomplish when a portal activates and registers itself with a portlet service. For the first item in the list "establish the portal vendors identity" we got into a general discussion concerning whether WSRP should support (vendor) extensibility. There were two concerns if we design in extensibility. The first concern is that it hurts/limits transportability of portlets. The second concern is that the extension mechanism opens the door for vendors creating defacto standards minimizing the control the WSRP group can exercise over the standard. On the first issue it was felt that extensions have to be optional. Portlets must be able to be written without using extensions and run (adequately) in any environment. If this is the case then using an extension is a choice left up to the portlet developer for gaining preferred behavior in a given environment. On the second issue, there was no direct response. Rather it was offered that supporting extensions reflects the environment we live in given the many (differing) portal products that exist. There was concern that without extensions WSRP becomes a poor man's portlet API -- one that (at least until it matures) becomes too low a common denominator for it to achieve as quick and far reaching success as we would like. We seemed to agree that though extensibility is a two edged sword we will support extensions.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC