[wsrp][interfaces] 4/11 Concall summary

[Michael Freedman <Michael.Freedman@oracle.com>]

The agenda for this meeting was to make a pass through the portal usage
document written during the prior week and discuss which operations
described in the usage should be the focus of our [future] discussion.

This is a short summary of what we decided.  More detailed notes are
appended thanks to Susan Levine.

1) Decided to refer to the Bind operation as Register
2) Decided that portlet templates will likely need to be addressed in
the initial specification but that it isn't a basic concept.  Hence will
lower its priority to address after the core is covered.
3) In the portlet template's section we decided to:  add an operation
for rendering the settings screen, and that you can get the settings
from the service.
4) We decided to defer the "migration" operations to a future revision
of the specification and for now allow vendor specific solutions.
5) We clarified the statement "You can upgrade a portlet template to a
new version." by adding the following wordings:  "You can upgrade a
portlet template to a new version of the portlet service".  We also
moved this operation into the "upgrade state".
6) We decided that cloning is a second order priority that can/should be
addressed once the core is in good shape.
7) We decided that converting a portlet instance into a portlet template
was an operation for future specification.
8) Clarified the portlet instance render operations to be
portal-centric.  For example, rather then saying "You can request a
portlet instance render its portlet content", we now say "Portal renders
portlet content".
9) We clarified that the number/types of renditions/screens is not
defined by the specification.  I.e. it is open.
10) We added a get personalization data operation to the portlet
instance.
11) We renamed offline/online to disable/enable for clarity.
12) We asked that more discussion/detail be given to "actions" and
"events" before deciding if they belong in our initial specification.
13) We deferred until the next meeting (because time ran out) discussing
operations relating to enabling/disabling a service and upgrading a
service.
14) All other operations are to be discussed/included in the
specification.

Next steps:
I am putting together a questions document to help frame the discussions
that need to occur to get us to the point of defining specific
operational requirements.

     -Mike-

--- Begin Message ---

• From: susan_levine@peoplesoft.com
• To: Michael.Freedman@oracle.com
• Date: Thu, 11 Apr 2002 09:11:10 -0700

Mike:  Any questions or comments on agenda for today?
(none)
What I propsed to do was to go through the list of operations, guage the
level of interest in including those operations in scope of the work that
we're doing.  Proposed answer 2 questions about the operation (as in
agenda).

Let the debate begin.

First operation: binding a portlet service, broken down into acquiring
portlet metadata, 2nd is the actual bind operation.

Member: should we specify a method?
Mike: let's defer those types of questions, just want to identify set of
operaitons we should focus on that we should begin debating and answering.
Let's avoid any real discussion on how that operation would be expressed.
Member: okay - with operation you don't mean soap op or cal, just the
logical op
Mike: logical op which we are ultimately going to have to specify something
in the spec.  The next step after this is capturing a bunch of questions to
frame the debate on each one of these operations, I'll be sending that out
tomorrow for all ops we agreed we need to be discussion.  Then we'll start
via email debating those things and next week we'll pick up from there.

Okay, moving on, questions or debate about acquiring metadata?  Okay, how
about next op, which is binding portlet service to a portal.  And I broke
the op down into a couple of pieces of function, 1) establishing portal
identity to portlet, 2) trust relationship 3), negotiating behavior
configuration between the two.  There's beena number of discussions that
teh result is the portal and portlet will have to negotiate on how th
eportlet will run in that portal, ie., where teh pers data is stored.   So
jsut at a hight level is there any debate about focusing on a bind op?

Member:  This gets confusing against the bind in step 0,
Mike: how about register?
Member: works for me, okay
Member: avoiding confusion is important
Member: I have a confusion about registrer, versus create portal instances
Sasha: register is the op that a portal does to a portlet where it
establishes identity, trust, etc., wehre create portlet template instance
may be an op that hte portal does after registration in order to represent
a design component fro its design community to develop portals with.
Thomas:  is it necessary for wsrp to have design component?
Mike: No we haven't decided that, just need to clarify diff between the
two.
Member: needs to be a diff name for this after you reg but before you
create a portlet template instance
Member: do you see an interaction btwn the portal and the portlet in that
state?
Member: yes, I think
Member: can you describe it?
Member: something that's reg int he portal at that point you can create
tmpleat instance, there is something in the portal that it knows about
Member: so you'd like to identify that particular state as a discrete
state, not that that state is itself an operation
Member: yeah, in the same way that having a portlet template instance is a
state that you call allow people to put instance on their pages.  There is
something there
Mem: could call it a registered portlet service
Thomas: more a registered service than a registered portlet, has to do with
service and portal, do reg just once for multiple portlet
Sasha: yeah, I think that's a great term
Mike: yeah and the op that occurs at that point is create portlet template
instance, pontentially.  I will update states to include that term.
Is there any disc or debate about register, the need for that operation,
etc.?
Mem: what do those mean?
Mike: establish trust - ongoing disc in security group, point in time in
which portal and portlet agree on how further comunication will be done i a
trusted environ and how the id of the portal will be transferred durign
comunication so the portlet can run at level of trust that it will run at.
Sasha: as long as its a potential op that's fine with me
Mike: there's no req that the portlet cares about any of these things
Sasha: things need to be reg before you create a template...    what do you
mean by negotiate behavior?
Mike: various discussions seem to imply that the portlet will in its
metadata signify ways in which it can or prefers to be managed, and the
portal may need to negotiate amongst the diff possiiblities of how to
manage it, there may need to be some communication where htey agree on how
it runs and behaves in that particular portal.  One example is where
personaliation data is stored.  One poss negotiation, portlet's metadata
prefers that pers data is stored in portal, and negotiation is portal ack
that it's going to occur or saying it can't satisfy that request.
Mike: okay moving on to next op, create portlet template instance.  I think
there will be debate here, Carsen?
Carsen: I like template as design entity, put it into toolbox, can be
configurable, put it onto a page, ubt I'm not sure it's necessary to define
in base WSRP interface, could add on top as secondary interface on top of
WSRP basic interface as simple as possible., for just data xfer, markup
xfer, not necesary to have this instance, it's a nice-to-have, more than
raw concept.  My concern is adding to base interface makes it too
complicated, if a service would just like to expose markup, be difficult to
support the interface.
<?>: if only way to create instance is from a template then difficulties
come into play.  If not the only way then you could have portlet services
that allow instances to be created directly.
Carsen: okya I would like that to be able to create an instance directly,
by giving id, service creates preconfigured instance of hte portal.  On top
of this you could have ID taht represents the template, to create instance
you'd pass handle of template to create the method....???
Mike: and the q I have for you Carson, is I understand layering approach,
it's not clear if you think whether we went for layering approach if you
think we should deal with anything other than lowest layer in the first rev
of the spec - should we defer it until we get the lowest layer defined.
Carson: my opinion, take the concept into account, not deal with it in the
first
Jeff: I concur, focus on lowest common denominator, make it as simple as
possible so we can achieve success, then evolve over time into more complex
situations.
Carson: exactly - should leave it open, concentrate on teh basics
Mike: I think we'll have to for a number of ops we defer to ta later
release we'll have to define the extensibility mech in the API so that
vendors who need to provide such ops it's well defined how they can do that
and layer on top of work that we've done.
SAsha: we will definitley need this functionality, we're going to end up
putting it in in our own way
Mike: yeah, we can talk about this, see if you could sway the folks that
want to keep it simpler
Sasha: all of our most important portlets do not work well without a design
time entity that people could modify
Alan: I agree with Sasha, coming as a portal maker ourselves, most of our
portlets or modules need to e configurable for all users, seems like the
template state seems to be the proper place for that macro level config
Member: what S wants it there's personalizaiton but not customization, but
??? can still implement it, not exposing it to end user.
Sasha: rgith which is essentially hacking together an admin interface to
make universal prefs make it look like personal prefs, seems a little bit
of a hack.
Mike: now one poss way to approach is to say that portlet template
instances are a lower priority at the moment as we go into discussion
phase, we concentrate 1st on those ops that are base, get those locked
down, then we come back and talk about the second tier of operations that
we think are common but not elemental.  but for those of you who want to
keep disc flowing and not make it complex, that might be a middle ground
that would allow vendors that have this kind of functionality to think
they'll get it into the first round of spec.
Carson: okay - common denominator, then talk about extending, if template
isntance are required (???too soft)
Sasha: I have abunch of cases where I think it is needed.  Could hack it by
reg service with various parameters hack it that way.
Mike: how about the claim that it's not elemental for first round of
discussion?
Sasha: sure.
Mike: so let's do walk thru portlet template ops with understanding that we
won't go into detail in discussions until we come back to it, but when we
do it will be good to understand what are teh ops. Any debate on using a
template to create a portlet instance? How about being able to modify
portlet template settings?
Carson: I think that's okay, <too soft>
Mike: still an open question, will get answered same way as we answer
personalization data.  the 2 kinds of data will logically or physically be
tied. We'll get into that disc quickly - that certainly is one of the hot
questions.
Mike: how about the copy operation?
Member: I can imaging a variety of reasons why you'd want to get the
settings... is copy just getting the settings and making a new template?
Mike: portal getting settings... who wants to get the settings?
Member: Trying to concisely say this....  can imagine scenarios where
you're attempting to keep synch view of state between portal and portlet
and template settings give you base that this comes from.  Q is is the
portal reuired to store these itself, can it get them from the template?
Mike: can you describe a situation where there's value in trying to keep
the synchronization? We talked about having one or the other store the
data, haven't talked yet about data being stored on both sides.
Member: there's a diff between storing it and having access at runtime.
value of access at runtime is a performance q of deciding when and how much
has to cross network boundary.
Thomas: at that point just copy such template once at design time,
performance <?> not important
Member: would prefer to at least copy it down<?>
Member: let's say portlet manages and stores own pers data, but a portal is
capable of building generic property picker, can build cust screen for a
portlet based on metadata descr of the propertties.in that world a get
settings op is valid, would give values that portal would use to update
cust screen.
Mike: so let's talk about getSettings, is that an op that we agree portlet
templates may interact with?
sasha:  yeah, also seems weird to have a get but not a set.  There's a
modify...  also point was you have a get and a create why do you need a
copy separately.  I would agreeget settings and create would be sufficient.
Mike: the descr of ops is from portal view as oposed to what's reflected to
api to portlets, no assumption that there's a physical copy operation that
there's a copy api, what I'm trying to describe is there's a copy op from
the standpoint of the portal , we need to discuss how that's communicated
to the portlet, may be just create isntance and get/set properties.
Sasha: understood, okay
Member: one of the things I look at is simplicity in interface, if we're
talking a higher view from portal side, coyp is useful, it's up to portal
auth to implement by a pair of calls, simplicity says drop it as interface
op, even if it's an abstract op in the portal.
Thomas: interface should not contain redundancy
Mike: well, may have redundancey or ability to do bulk request, sometimes
too atomic operations give you performance concerns.
Member: design ops are more performance tolerant than runtime.
Mike: from abstract point of view we agree that copy is an op, and debate
is how to ensure express that op is executable in the api.

Mike: delete a portlet emplate, any debate on that?
Alan: when you delete a template, what happens to instances that may have
been created?
Mike: good q, will have to define that.  If you want my short answer, I
think those instances stay around.
Thomas: agreed
Mike: now if unbound portlet service taht would be a different story, but
we'll have to debate that behavior.
Jeff: one thing, I think some of these discussions, for the domain of the
diff portal vendors, I still vote for simplistic api to establish between
consumer and producer some of the things we're discussion will be where the
diff portal vendors will distinguish themselves.
Mike: right, might be left up to whatever a vendor wants to do, that's a
good point.

Mike: migrating  aportlet template.  Means that  a template descr is
transferred from one portal to another portal, described in relation to be
able to support a publishign function where someone is working in a
development environment, need to stage the portal and publish to a
production environment.
Member: a useful scenario, I would get concerned having it part of the
standard, have to cover case where this is 2 dissimilar portals that you're
xfering between, has impacts on trust relationships we looked at in reg
phase.
Mike: agree, we can ack we're going to have to discuss this, I would tend
to not disc in first rev
Sasha: also seems like it requires portal to portal communicaiton not
portal to portlet, whichis what we've concentrated on.
Thomas: seems to be vendor specific
Alan: I have simple use case, if a portal is installed ina clustered
environment, we'd have mult instances o fsame portal in which the migration
would take place in a well defined manner.
Mike: wasn't intending for cross vendor migration, just for migration
within a portal type.
Sasha: seems like only reason to put instandard is if you want to be cross
vendor
mike: well if it turns out all vendors end up having to solve this problem
and it involved api's to the portlet, then it mihgt be something to
include. My take on this is we don't have enough info and it's a secondary
function and we should defer it. We may find it becomes something for
standardization.
Member: is this the portal that currently has the tmplate doing a get
settings, new porta doing a create template.
Mike: yes, and it gets simpler because you've broken it down to atomic
operations.  Lets defer breaking it into ops that are necessary to some
later revision.
Mike: final one is that you can upgrade a portlet template to a new
version.
Sasha: don't understand this one
Mike: if you modify the meta data of the portlet service, there are
implications to both template and instances based on those modifications.
So all these upgrade bullets are to cover those situations where you have
to account for fact that metadata has been modified in the lifecycle of the
service.
Sasha: you're talking about developer of a portlet service, yes?  So if you
change hte metatdata of a portlet service.  I think that would be then all
one operation, could upgrade for teh service would entail all these other
things.
Mike: correct.  what would need to happen if a portal invokes an op that
doesn't comply with the new metadata but it did comly with the old
metadata. Specify out what the expected behavior is in the case where you
can adjust or you can't adjust.  Portlet service upgrade is op that kick
this all off.  Placeholder for us to see if we wanted to describe what
happens to a portlet template when a portlet service and it's metadata is
upgraded.  Does that seem fair?
Sasha: interesting disc, don't really see if as a separate operation, but I
can see it either way.  Would call out that new version of portlet service,
it wasn't clear to me you wanted to version portlets it the template, some
instances deal with old metatdata, some new metadata...
Mike: I'll clarify that.
Sasha: would put it as bullet underneath upgrading the service.
Mike: will do
Mike: okay moving on to instance ops, let me add the getter as well to
portlet instance, for same reason as for portlet template. Why don't folks
call out their favority one we don't need to be doing at this point, then
we can walk thru that small list.  Anything that isn't raised we'll assume
you agree we should talk about.
Thomas: from my point of view we should discuss if actions and events are 2
diff things and define what they really are.
Member: agree, don't understand how they differ, don't have enough info to
know what of the 2 or if eithe rof the 2 should be included in spec.  We
need to discuss at higher level what these are before we discuss whether
they belong.
Thomas: can always think of advanced event...
Member: let me explain diff.... action is what we .. op from end user to a
specific portlet.  Event is something one portlet sends to another portlet
or group of portlets.  Not tied to end user, might be generated as result
of an action but still between portlets.
Mike: I'd started with that as high leve, what I want to get into post this
meeting is detailed disc of the rules and behaviors how they differ for
actions and events, whether actions are just a diff word for event because
they happen to be invoked by user, or if they're diff because they have
diff rules and behaviors. I need to have more detail about what folks are
expecting in these areas before I can make recommendation about
appropriateness to spec.
Thomas: will write up my understanding.
Member: also ??? is writing use case in next couple of days
Mike: yeah, it'll be relatively easy to describe value for events, debate
is whether it'll be a first tier function or not.  will defer until we get
better clarification.
Mike: other ops for debate?  I've seen discussion about clone and copy.
Member: yeah clone is interesting ?? op, it has no effect on portlet on
producer so it shouldn't be part of discussion here
Mike: I'd liek to defer whether it has impact on portlet, sound slike from
operational standpoint it's valid, we need to know if it involves the
portlet.  If not we'll get rid of it ... can we leave it open as a
placeholder with that question if it involves portlet as an op?
Sasha: relatively low priority, don't see use case for cloning, understand
it as a logical op though.
Mike: will provide example offline about this.  I agree, if cloning wasn't
defined & one or two protal vendors who saw value invented a way to do
cloning, that would be okay.  by cloning that means specifying hte ability
for multiple portlet instances to hsare same pers data, that's teh root of
what the op is about.   We probably think there's value there but we may
not need to burden ourselves with specing in the api how to make that
occur. correct?
Sasha: yeah.  I have 2 other things: 1) I'm not sure I agree w/your descr
of heirarchical personaliation data...
Mike: yeah don't take that part as gospel, used that more as explanation
and expect a lot of discussion about pers data, levels of pers data, etc.
Sasha: great...
Member: I think this is a statement about the portal and quesiton it's
relevance to wspr
Mike: agree, calling it out was because of emails about pers management, if
there is a relationship between pers data either heirarchical or level
fashion, it potentially puts a burden on the portlet.  It's for further
discussion.
Sasha:  other thing I would say, is I want to call out it doesn't mean
things that are just in the portal page, there can be many click through
view, look at an email, read a news story...
Mike: can you distinguish between whether that's in or out of teh context
of the portal, ist he click thru direct communcation to the provider from
teh client or is it mediated by the portal?
S: mediated
Mike: then it's meant to be included in teh request portlet content
S: ???
Mike: tried to avoid use of term page and those kinds of things because I
didn't want to make assumption about rendering context
S: op to render a link reference to itself...
mike: yeah, there are user interface design patters which are used for
smaller screen devices in which commonly displya pages more as menus... and
so the link ref to yourself is an op which says, how do you identify, how
do you id it in the menu when you're not asking for its content.
Thomas: but hte aggregator has enough info to generate this link
Mike: yeah, but what if hte name (title) that wants to get used for that
link is something the user can customiaze and the portlet is mainintning
ucst
s: yeah, portlet oculd generate like a summary and the thing you put on the
mnue is the portlet, then the other is the mneu items being text coming
back from the portlet and htey link back to something else.  I don't
understand case in whicn it has to do this...
Mike: portal needs to render a link ref to the portlet, I agree we don't
need to make assumption if that translates to a request to the portlet
instance to render a link to itself.  So I'll reword "you can request" to
"the portal is... needs to render this information" then we can discuss
later what operations the portal uses to actually accomplish that funciton.
S: relatively important use case on that is be ablet o send html emails to
folks with links back to...
Member: is this link ref to be valid what you're talking about is a portlet
service, says the portler service has to have http binding.
s: not link to portlet but portal displaying that portlets content
m: not sure portlet can render in that case
S: ????
Link ref to itself not http ref to itself, no assumption of the protocol
that url returns, urls are protocol independent.
Member: other thing is you called out 4 types of screens a portlet could
render: current/help/about/personalization.  Do we want to think of these
as distinct operations or you can request an instance to render current
content, it can set its state and make this an extensible set?
Mike: I tend to agree that's a good way to expres the operaiton, was just
trying to call out the operational functions from the portal perspective
Member: not making it explicity these four types
Member: open action model so they can define these on their own.
Sasha: also good to talk about portal template rendering it's customization
screen.  As logical op... these are the things it could do..
Member: just has to do with how closed a set it appears to be.
Mike: want to make number of screens open not closed, I agree.
Sasha: important to call out the ones we know we'll need though.  And then
the portlet template needs the same thing.
Mike: for all of these things I make note of, if I've neglected to include
anything, let me know and I'll go back.
Any other instance operations to talk about?  FOr example I might suggest
that converting a portlet instance to a portlet template is potentially
something for the future rather than now.
Thomas: agree
Mike: any other comments on that?
Member:  only other comment, service off line and coming back on line, it
might just be clarifying what you mean there, at level of wsdl bind/unbind,
or is it register, deregister?
Mike: this is while you are registered, there may be times when the portal
or portlet decides that communication should not occur for the time being.
<missed 1 minute>
it's a service operation not on an intsance basis, you did it on the whole
class.
Why don't we clarification, we can pick that up next thursday if we don't
do it over email over the course of the week.
Same for the upgrade, other ones are... what I'll do next is begin to
regenerate teh list of questions that I've accumulated from emails under
each operations, suggest areas for us to begin talking about right away.

Okay, lets wrap up...
Thomas:  this time next week is in the middle of the WSIA face to face...
Mike: let's wait 2 weeks for the next concall if that seems agreeable to
folks and just do discussion via email.

--- End Message ---