OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsia message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: [wsia] Fwd: [wsrp-wsia] [wsrp] WSRP Conference Call - Sep. 26 2002 -Meeting Minutes


Title: Fwd: [wsrp-wsia] [wsrp] WSRP Conference Call - Sep. 26
I am forwarding this with the minutes file included in the message because I can simply use the URL to the mail archive for it in the WSIA website to make the minutes available to the public on the website without the otherwise necessary step of turning it into an html file, which is easier since all I have to do is post this and add the url to website file.

Ciao,
Rex

WSRP Conference Call - September 26, 2002

Roll Call

Chair:  Thomas Schaeck, IBM

Stephen Drye, Art Technology Group
William Cox, Bea
Adrian Fletcher, Bea
Andre Kramer, Citrix
Timothy N. Jones, CrossWeave
Alan Kropp, Epicentric
Madoka Mitsuoka, Fujitsu
Carsten Leue, IBM
Rich Thompson, IBM
Eric van Lydegraf, Kinzan
Mark Cassidy, Netegrity
Chris Brown, Novell
T.J. Cox, Novell
Michael Freedman, Oracle
Mike Hillerman, Peoplesoft
Sasha Aickin, Plumtree
Yossi Tamari, SAP Portals
Alejandro Abdelnur, Sun
Eilon Reshef, WebCollage
Gil Tayar, WebCollage
Brian Dirking
Monica Martin
Ravi Conuru

Prospective Members:
Shumaker Gennady
Rex Brooks
Richard Cieply
Steven Smith

Discussion

TS:
Meeting Acceptance from last meeting.  Are their any updates or issues with last weeks minuts?
<no issues>
Minutes are accepted.

Ok, time for a new volunteer for secretary.  Looking for a volunteer.
<long silence>

Steven Smith:  What are you looking for a volunteer for?

TS:  WSRP TC Secretary until the next F2F.

Alan:  Why don't I take it.

TS:  Thank you very much.  On to the agenda.  I'm going to turn it over to Rich to go over the issue list.

RT:  Need to vote on two things.  Propose deferring adding a lease concept related to registration to version 2 of the spec. 

Sasha:  Do we have a Quarum?

MH:  Yes. (23 of 36 or 63%)

RT:  A yes vote is to defer this item to version 2:  19 Yes, 1 No, 3 Abstain

Proposal to rename Expire

RT:  Proposal to rename expires field in the context structure.

?:  I'm in favor of an explict expires.  Should be in line with WS Security.

RT:  Vote:  Yes vote to rename the expires field in response context to refHandleExpire.

?:  Why don't we call this SessionExpires?

RT:  <missed the answer>

MF:  All other situations in which we have a handle with fields associated with that handle, the fields are named by that handle.

Gil:  This has something to do with this concept in WSRP that does not have a name the I refer to as "the runtime entity".

MF:  I would like to wait until the next draft of the spec before dealing with this issue.

Gil:  Ok

Gil:  So, lets leave response context as it is.

RT:  This specific issue has been before us for a week, but we do have the larger issue discussed in Mike F's email.

TS:  We should rename the thing to make it consistent and allow spec editor to work on larger issue.

Process for handling editorial issues

RT:  A lot of things I see are actually editorial issues instead of technical issues requiring a vote of the TC.

?  Agree.

MF:  You should pre-publish how you plan to address an editorial issue.

RT:  Agree.

Gil:  So you are saying leave all of the minor editorial issues to Rich and Co., and bring technical issues to the group.

MF:  Leave editorial issues to Rich unless someone demands a vote.

RT:  New issues, there are 3.

Publishing to UDDI

#1  Publishing in UDDI.  Should only Entities be published, producers, or both.

Carsten: 

Publish producer endpoint and use entity self description methods.
Or
Publish entities into UDDI directory.

The entities are not services, but rather subservices.

Gil:  UDDI is not that important in the market.  Perhaps we should just defer it.

Carsten:  I object.  It is necessary to have some search capabilities.  UDDI is the best search option available.

Bill:  UDDI is not the only way this will be done. EbXML is another.  Put a recommendation in on how to publish to UDDI, but not make it part of the standard.

MF:  I'm not sure POE's are the way to do this in version 1. 

Bill:  This probably does need to be deferred, but it needs to come into the spec in some future date.

Carsten:  How will portal administrator search for portlets?  Will they type in endpoints?

Bill:  UDDI is not a standard and folks have been using other methods for some time.  Why do an extensive job on something that has low market presence.

TS:  Background on why I proposed this:  allows portal administrators to publish things without doing any programming.  Other portal administrators could find these services.  UDDI seems to be the only option available.

MF:  Searching is not in 1.0.  We have discovery but not search.

Gil:  How many portal vendors will publish their portlets in the global UDDI registry.

TS:  IBM has already done it.

Bill:  This should not be in this spec, especially in 1.0 of this spec.

<4 agreements>

MF:  Should we be discussing implementation details of how to publish to UDDI?

Bill:  There is a lot of potential discussion and we don't have the people we need to have the discussion.  Don't require an implementation, but provide the information necessary.

TS:  Need to enable interoperability between portals.

Bill:  I don't think can be a normative part of this spec unless we add a lot of time.  It doesn't sound like you have majority of folks on the call that want to do this.

TS:  There are two questions.  Should this be normative part of spec or non-normative?  How should it be described?  POE or producer endpoints only.

MF:  I am hearing that there are lots of other registries that they have to deal with that are not UDDI.

Bill:  This is not a technical issue but a political and market acceptance one.

<more discussion along the same lines>

Ravi:  We need to define at the WSDL level the entities that can be accessed.

MF:  Isn't that getServiceDescription.  You can always make a runtime call to the producer to find out the services available.

Bill: UDDI is not acceptable as a normative part of this spec, and barley as a informative part.

Bill:  We don't need to provide a mechanism to publish, we need to provide the information necessary .

TS:  We need both.   It seems the group feels this should be non-normative.  So we can define in the non-normative section how to register to UDDI

MF:  I'm going suggest then that we not deal with non-normative items for the next two months.

Andre - we need to define getServiceDescription

MF:   We need to make sure getServiceDescription will work for things like UDDI.

TS:  As a side activity drive forward the recommendation of how UDDI might be used.   The WSRP protocol has priority and must be defined.  When it is solid we can readdress UDDI.

Yossi:  I think UDDI is a must for interoperability. 

<multiple discussions at once>

MF:  It seems we are just deferring this debate if we follow TS's recommendation. 

Ravi:  Everyone agrees we need to fix the information model.  Let the folks who are interested in a particular registry work on it on the side.

Bill:  If you are going to do it for 1 registry I disagree, if you are going to for multiple them I'm ok.

Gil.  We don't have a lot of time.  We need to do the information model.  But we don't have time to focus on UDDI.

MF:  We come to some kind of agreement that this will happen in 1.1.  It's going to take time to work thorough it.  We need to take it off the table between now and January.

TS:   Proposal is to concentrate on protocol.  Then go into data model that describes the services.  Then work on the mappings to search and discovery mechanisms.

MF:  The last one is post 1.0

TS:  That may be the case.

TS:  So is information is available on the entity level or the service level?

Bill:  This is a big item that is not ready for vote.

RT:  Do we need a group to spin off to work on this information model?

MF:  What are the consequences to going with the simple approach of the producer model.  It can be extended to the entity model if necessary.

<lots of discussion on this point>

Bill:  I would like to see this question restated in the information model context before we spend anymore discussion on this.

MF:  I was asking if we should separate this question into two stages and concentrate now on the service publishing and defer entity publishing.

TS:  I think that would be a reasonable approach.

Carsten:  Can this be discussed in mail.

MF:  Yes.

Group ID

RT:  #4  What is the meta data that is truly needed if consumers are going to direct how shared sessions are grouped.

?:  In JSR168, all the portlets in a producer have an application scope. 

?:  This is related to the sideline discussions of initEnvironment and how to establish session with the producer.  Producers will have to code themselves appropriately.

MF:  Group ID direct how sessions should be grouped.  In v1.0 all portlets from the same producer for a user can be grouped using the group id. 

RT: for any 1 end user, the group id is identical for any portlet from one producer.

MF:  Right.

Yossi:  Does this mean group id maps to user's client session.

MF:  Yes.

Yossi:  Should we rename it.

MF:  We are looking forward to how it will be used in the future.

<discussion>

MF:   Group ID could be removed.  JSR 168 does not need it.

MF:   It would mean initEnvironment would be required for producers who want to share sessions.

<discussion >

MF:   Maybe we should leave the question of group ids for next week and give folks a week to debate it.

Yossi:  Can we motion to move this to next week.

MF:  Second.

RT:  Ok, will move it to next week.  Proposal is to removed Group  ID from the protocol.

Refresh flag

RT:  #5  isRefresh Flag

AA:  We will be closing on this subject next week.  The idea is a portlet that is not performing a peformInteraction but need to call back to itself.

MF:  Propose we defer this discussion for two weeks.  JSR is addressing this and it may no longer be an issue.

RT:   Ok.

Gil:  How would the consumer know to send refresh.

AA:  Would be passed to portlets not received performInteraction.

Gil:  It has nothing to do with F5 refresh.

MF:  Right

Carsten:  I just want people to know that this is really a backdoor to action processing.

Mapping portal concepts to protocol concepts in the spec

RT:  Do we want to describe the realationship with portlets portlet instances POEs and CCEs.

TS:   What part of the spec would this go?

RT:  Good question.

MF:  Can we put this on the list for next Thursday.

TS:  <missed this>

MF: Answer has to be "yes"
TS:  Yes, this should go in the introduction section.

<discussion>

MF:  We are not clear about this in our group. 

RT:  We've been focused on the more normative parts of the spec so I don't know that this will get in by tomorrow.

MF:  I would prefer you are happy with the re-write as opposed to publishing it
tomorrow.

Misc.

TS:   Ok, do we have other topics for today?

MF:   Can we defer caching past next week?   We could do it next week, but I suspect is will just get deferred.

RT:  OK, we have lots of stuff on the agenda for next week.

?:  Is the next F2F 5 days?

TS:  Yes.  Friday may end at 1 PM

?:  How soon do we have to give notice?

TS:  As soon as possible.

?:  Where in New York?

RT:  Charile is working on that.

End of meeting.




Date: Mon, 30 Sep 2002 14:45:47 +0200
From: Thomas Schaeck <SCHAECK@de.ibm.com>
Subject: [wsrp-wsia] [wsrp] WSRP Conference Call - Sep. 26 2002 - Meeting
 Minutes
To: wsrp-wsia@lists.oasis-open.org
Importance: Normal
Sensitivity:
List-Owner: <mailto:wsrp-wsia-help@lists.oasis-open.org>
List-Post: <mailto:wsrp-wsia@lists.oasis-open.org>
List-Subscribe: <http://lists.oasis-open.org/ob/adm.pl>,
 <mailto:wsrp-wsia-request@lists.oasis-open.org?body=subscribe>
List-Unsubscribe: <http://lists.oasis-open.org/ob/adm.pl>,
 <mailto:wsrp-wsia-request@lists.oasis-open.org?body=unsubscribe>
List-Archive: <http://lists.oasis-open.org/archives/wsrp-wsia/>
List-Help: <http://lists.oasis-open.org/elists/admin.shtml>,
 <mailto:wsrp-wsia-request@lists.oasis-open.org?body=help>
List-Id: <wsrp-wsia.lists.oasis-open.org>
X-Rcpt-To: rfc822;rexb@starbourne.com
X-DPOP: DPOP Version 2.4a
Status: U

The minutes from last weeks call - thanks Mike !

---------------------- Forwarded by Thomas Schaeck/Germany/IBM on
09/30/2002 02:26 PM ---------------------------

michael_hillerman@peoplesoft.com on 09/28/2002 02:29:41 AM

To:    wsrp@lists.oasis-open.org
cc:
Subject:    [wsrp] WSRP Conference Call - Sep. 26 2002 - Meeting Minutes



Minutes from yesterday's conference call.

(See attached file: WSRP Conference Call 09-26-2002.doc)


(See attached file: WSRP Conference Call 09-26-2002.doc)



-- 
Rex Brooks
Starbourne Communications Design
1361-A Addison, Berkeley, CA 94702 *510-849-2309
http://www.starbourne.com * rexb@starbourne.com

Attachment: WSRP_Conference_Call_09-26-2002
Description: MS-Word document



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC