[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [wsrp][markup] UPDATE: Minutes for 5/8/02 conference call
Your first point is covered by the discussion of having portals separately
provide for the proxing of resources.
Your second point is reinforcing the design I commented on where a portlet
can indicate that it is willing to dynamically write its URLs for
redirection through the portal. If the portal supplies the required
information, the portlet does the URL writing in a manner that eliminates
the need for the portal to parse the presentation fragment looking for URLs
to rewrite. If the portal does not supply the required information (will
always occur when the portlet is unwilling), then the portlet prefixes URLs
needing to be rewritten in a manner the standard defines (discussion point:
should this be dynamic ... ie prefix defined by the portal. My current
sense of the discussion is 'no') and the portal then parses the
presentation fragment to locate/rewrite the various types of URLs.
Khurram_Mahmood@peo
plesoft.com To: eilon.reshef@webcollage.com
cc: "'Gino Filicetti'" <gfilicetti@bowstreet.com>, "'WSRP
05/08/2002 07:21 PM Mailing List (E-mail)'" <wsrp@lists.oasis-open.org>
Subject: RE: [wsrp][markup] UPDATE: Minutes for 5/8/02
conference call
1. There is another issue that might show up in production environments.
That is the issue of using different url's for different content references
in the html document.
So for example, the portal might want all the references to the javaascript
files (i.e. <script src="foo.js"..../>) to have the
http://cacheserver/portletname/js/ directory identifier appended to the
server name but for all form submit action attributes might need some other
url like http://portalserver/portalservlet/ appended to the server uri.
My point is that whether a portlet is doing url re-writing or the portal is
doing that, the portal needs the ability to specify multiple urls each for
a different reference type inside the portlet's html. This is important
especially because portal should be caching the images/javascript/css etc.
static content instead of retrieving it everytime. It easy to setup a
mime-filter that redirects to the right location but it's better if the
spec takes care of it.
2. Purely from a performance standpoint, it makes more sense for the
portlet to do the substituion of portal url(s) into its html/js etc. files
before sending it out. That distributes the work that a portal has to do
and makes for a more scalable solution.
Thanks,
Khurram Mahmood
"Eilon Reshef"
<eilon.reshef@webc To: "'Gino
Filicetti'" <gfilicetti@bowstreet.com>, "'WSRP Mailing List (E-mail)'"
ollage.com>
<wsrp@lists.oasis-open.org>
cc:
05/08/2002 03:46 Subject: RE:
[wsrp][markup] UPDATE: Minutes for 5/8/02 conference call
PM
Gino,
I would like to second Rich's point regarding passing enough information to
the portlet so that URLs can be written correctly in the first place if
needed.
An example I incidentally sent a couple of minutes ago to the WSIA group
(under a separate discussion) was a JavaScript example such as the one
below (which isn't necessarily a real one):
<script>
var target = "http://"; + gMyDomain + "/mypage.rgb?page=" +
document.form[1].pageNumber.value;
document.location = targert;
</script>
If such a script appears in a portlet, the Portal has no way to route the
action correctly, so if the Portlet won't change the code, action routing
won't work. So, I believe we need to let the Portlet receive - as part of
the protocol - the relevant Portal's URL to allow it to generate the
JavaScript correctly. This also means that if the Portlet is sophisticated
enough, it would also be able to write the rest of the URLs correctly and
save CPU time on the Portal end. And, this will also allow action routing
from Flash files, etc.
Please note that the same scenario is also applicable to image routing,
where in the common example of roll-over images, the roll-over images are
typically loaded using JavaScript code.
My two cents,
Eilon
-----Original Message-----
From: Gino Filicetti [mailto:gfilicetti@bowstreet.com]
Sent: Wednesday, May 08, 2002 5:05 PM
To: WSRP Mailing List (E-mail)
Subject: [wsrp][markup] UPDATE: Minutes for 5/8/02 conference call
I've just included one of the URL demarcation proposals that Rich
recently
wrote up to the minutes in the URL Rewriting section....
Please find the update minutes attached.
G
> -----Original Message-----
> From: Gino Filicetti [mailto:gfilicetti@bowstreet.com]
> Sent: Wednesday, May 08, 2002 4:42 PM
> To: WSRP Mailing List (E-mail)
> Subject: [wsrp][markup] Minutes for 5/8/02 conference call
>
>
> Folks,
>
> Please find attached the minutes for the latest conference call of
the
> Markup subcommittee. The agenda we followed appears below.
>
> David Taieb will be updating our master document to capture
> the progress
> that was made in today's call and will be sending that out
> for review in the
> next few days.
>
> Gino
>
>
> > PROPOSED AGENDA
> > ~~~~~~~~~~~~~~~
> >
> > Markup Tags
> > ~~~~~~~~~~~
> > - The list of DISALLOWED and DISCOURAGED tags for HTML and
> > XHTML Basic are
> > as follows:
> > HTML:
> > Disallowed: base, body, frame, frameset, head, html, title
> > Discouraged: link, meta, style
> >
> > XHTML Basic:
> > Disallowed: base, body, head, html, title
> > Discouraged: link, meta
> >
> > - Question: What does it mean for a tag to be DISALLOWED?
> > Does the inclusion
> > of a disallowed tag invalidate the whole markup fragment?
> >
> >
> > Style sheets
> > ~~~~~~~~~~~~
> > - This is the full list of styles submitted by Alan Kropp
> > (WSUI) and Thomas
> > Schaeck
> > (WSP) organized into groupings:
> >
> > Fonts:
> > wsui-font
> > wsui-font-small
> > wsui-font-large
> > wsui-dim
> > wsui-dim-small
> > wsui-error
> > wsui-error-small
> > wsui-ok
> > wsui-ok-small
> > wsui-form-label
> > portletText
> > portletSmText
> > portletTinyText
> > buttonText
> > fieldErrorText
> >
> > Tables:
> > wsui-table
> > wsui-table-row-header
> > wsui-table-row-sectionheader
> > wsui-table-row-odd
> > wsui-table-row-even
> > tableHead
> > tableText
> > tableShdRow
> >
> > Sections:
> > wsui-section-title
> > wsui-trail
> > wsui-trail-current
> > portletTitle
> > portletTitleCust
> > portletHead
> > portletBody
> > portletBack
> >
> > General:
> > wsui-page-title
> > wsui-block-bgcolor
> > portletColorBack
> >
> > Menus:
> > wsui-menu
> > wsui-menu-current
> >
> > - we need to come up with a naming convention, and rename all
styles
> > - we need to trim the list and delete duplicates
> > - Question: Should the spec provide a default set of values
> > for the styles,
> > or just
> > the names and a description of the styles themselves?
> >
> >
> > Secure Resources
> > ~~~~~~~~~~~~~~~~
> > - How do we deal with signed java applets, images and other
> > resources that
> > the client may not have access to?
> >
> > Two approaches envisioned...
> > 1. The aggregrator proxies the request from the client to the
> > remote portlet
> > and proxies back the resource to the client.
> > 2. The aggregrator caches the resource from the remote
> > portlet and serves it
> > to the client.
> >
> > - We need to come up with pros and cons of each approach.
> > - Also open to any other approaches that people may come up with.
> >
> >
> > URL Rewriting and Namespace Encoding
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > - go over the following 3 scenarios, and come up with a list
> > of pros and
> > cons
> >
> > Scenarios:
> > 1. Aggregator sends a prefix w/ request and portlet must use
> > it to do the
> > URL boundary demarcation. The aggregator then parses the
> > markup looking for
> > the prefix it provided.
> >
> > 2. All portlets use a predefined prefix which is part of the spec
to
> > demarcate URL boundaries. The aggregator then parses the
> > markup looking for
> > the well known prefix.
> >
> > 3. The aggregator automatically parses markup and
> > heuristically determines
> > URL boundaries and does the necessary rewriting automatically.
> >
> > - Question: Will namespace encoding use the same method as
> > URL encoding? Are
> > there any specific differences between the two?
> > - Question: Should we mandate the elements that should be
> > namespace encoded
> > or leave it up to the portlet developers to decide? Problem:
> > If we mandate
> > the elements, then the spec will need to be constantly
> > updated to support
> > new technology and we would have to explicitly cover a good
> portion of
> > existing scripting languages, markup languages etc....
> >
> >
> > Leadership Succession
> > ~~~~~~~~~~~~~~~~~~~~~
> > - Due to increasing time constraints and an ever tightening
> > schedule, I'm
> > going to have to relinquish my duties as the leader of this
> > sub-committee. I
> > fully intend to remain an active member of this group and to
> > help out as
> > much as I can, but I'm afraid I just can't dedicate the time
> > necessary to
> > staying on top of all the discussion, making the concall
> > agendas and leading
> > the discussion on the phone. We can, however, continue to use
> > Bowstreet's
> > conference call facilities (which includes nice things such as
call
> > recordings to facilitate minute taking) indefinitely.
> >
> > - I'd like to select the new leader during this call and
> > transfer over the
> > leadership of the calls starting with our subsequent
> conference call.
>
>
>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC