wsrp message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [wsrp] how to support cHTML with WSRP and JSR168?
- From: Walter Haenel <HAENEL@de.ibm.com>
- To: Richard Jacob <richard.jacob@de.ibm.com>
- Date: Tue, 7 Dec 2004 21:27:00 +0100
Richard,
using the userAgent string won't solve
the problem. There are devices out in the market in different versions
for different markups, but they are using the same userAgent. Thus to assume,
that the userAgent is unique is an invalid assumption. Further more, you
don't really want to update your portlets to support a new device with
a new user agent.
Mit freundlichen Grüßen /
Have a nice
day
Walter
Hänel
Pervasive Computing - Portal Development
Tel. +49-7031-164523
Fax +49-7031-164888
Richard Jacob/Germany/IBM@IBMDE
07.12.2004 17:08
|
To
| Andre Kramer <andre.kramer@eu.citrix.com>
|
cc
| wsrp@lists.oasis-open.org
|
Subject
| RE: [wsrp] how to support
cHTML with WSRP and JSR168? |
|
Agreed, this is what I described below (using just the userAgent string).
But we don't have a means to describe the support in the service
description /portlet description.
Mit freundlichen Gruessen / best regards,
Richard Jacob
______________________________________________________
IBM Lab Boeblingen, Germany
Dept.8288, WebSphere Portal Server Development
WSRP Standardization Technical Lead
Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888
Email: mailto:richard.jacob@de.ibm.com
Andre Kramer
<andre.kramer@eu.
citrix.com>
To
wsrp@lists.oasis-open.org
12/07/2004 03:35
cc
PM
Subject
RE: [wsrp]
how to support cHTML
with WSRP
and JSR168?
Putting aside the question of why consumers (re-publishing to PDAs) could
not recognize and use a special set of portlets for what is largely a
legacy markup model, these consumers would pass through the "user
agent
header" of their clients, allowing each portlet (or the producer)
to
generate the right cHTML/vanilla HTML flavor.
Regards,
Andre
From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: 07 December 2004 14:05
To: wsrp@lists.oasis-open.org
Subject: RE: [wsrp] how to support cHTML with WSRP and JSR168?
I suspect publishing the portlet twice like this would cause more problems
than it would solve (Consumers that ignore the difference have a 50% chance
of using the wrong POP). Using an optional mime parameter at least helps
things work most of the time. If there was an agreement on the parameter
to
use, then interoperability on the use of cHTML could also be achieved.
Rich
Andre Kramer
<andre.kramer@eu.citrix.com>
To
12/07/2004 05:55 AM
"'Richard Jacob'"
<richard.jacob@de.ibm.com>,
wsrp@lists.oasis-open.org
cc
Subject
RE:
[wsrp] how to support cHTML
with
WSRP and JSR168?
The only thought I had was that the Portlet could be published twice, as
two portlet descriptions, both with the "html" MIME markup type,
but one
pop handle for cHTML and another for vanilla HTML consumers. An optional
MIME parameter could also be used but would (as you suggest) be likely
to
be ignored.
Regards,
Andre
-----Original Message-----
From: Richard Jacob [mailto:richard.jacob@de.ibm.com]
Sent: 07 December 2004 10:06
To: wsrp@lists.oasis-open.org
Subject: Re: [wsrp] how to support cHTML with WSRP and JSR168?
I know this mail was lengthy :-)
Anyone an opinion on this?
Mit freundlichen Gruessen / best regards,
Richard Jacob
______________________________________________________
IBM Lab Boeblingen, Germany
Dept.8288, WebSphere Portal Server Development
WSRP Standardization Technical Lead
Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888
Email: mailto:richard.jacob@de.ibm.com
Richard
Jacob/Germany/IBM
@IBMDE
To
wsrp@lists.oasis-open.org
12/02/2004 07:18
cc
PM
Subject
[wsrp] how
to support cHTML with
WSRP and
JSR168?
Hi all,
as you might know unfortunatly the W3C cHTML specification has missed to
register its own mime type and instead uses text/html as the mime type
for
cHTML.
Efforts to try to register a specific mime type for cHTML failed for
backwards compatibility reasons.
The W3C recommendation is to use the userAgent string to distinguish which
html to generate: plain HTML or cHTML.
However, this brings us some problems for portlets:
1. How can portlets indicate that they support HTML and cHTML?
2. How can the Consumer explicitly request cHTML markup for its end-user?
Assume the following use case:
A portlet supports HTML with the modes view, help and edit AND cHTML with
the modes view, preview, help.
The question is what the PortletDescription contains for the text/html
mime
type for the supported modes.
With the current WSRP & JSR168 specification we need to end-up with
the
superset of both modes arrays, i.e. the portlet description would contain
one single text/html mime type with the modes view, help, edit, preview
and
help.
This is quite unsatisfactory as the Consumer portal for example would
render decorations which would allow edit mode even for cHTML only capable
devices since it can't distinguish the HTML dialects.
One possible solution to this problem would be to define an additional
mime
type parameter like "html-dialect=cHTML".
This would mean that the PortletDescription would contain two MarkupType
entries for the mime type text/html:
"text/html" for plain html and "text/html; html-dialect=cHTML".
In the same way the Consumer could explicitly request cHTML content by
setting the mime type to "text/html; html-dialect=cHTML".
The problem here is that we explicitly say in the WSRP spec that
Consumers/Portlets do not need to handle any optional parameters for mime
types.
It seems to me that this is quite limiting.
When we look at xHTML there are already optional parameters used to
distinguish between various profiles. It seems natural to me that portlets
supporting xhtml might have different sets of modes and window states
depending on the profile.
Also in future further mime types might come up which use parameters on
mime types to distinguish between various
subtypes/profiles/versions/dialects.
So this comes down to two questions:
1. Should we expand the handling of mime types in such a way that
additional parameters DO care?
This would mean that "type/subtype; param1=value1" is being considered
as a
different MarkupType than "type/subtype; param2=value2".
2. Should we add a specific parameter for cHTML?
I am aware of the fact that this is a "workaround" for the missing
mime
type.
While cHTML generation based on the userAgent string might work well for
plain web apps, this approach seems not to be well suited for the portal
use case where the consuming portal could do better if the supported
modes/window states for a certain MarkupType were known a priori.
Did other portal vendors experience similar problems with cHTML support?
And if not, how do you solve it?
We could solve our use case by having our own extension for this, however
this would require us to replicate the MarkupType structure for cHTML and
add it as a PortletDescription extension which is not very convenient.
Mit freundlichen Gruessen / best regards,
Richard Jacob
______________________________________________________
IBM Lab Boeblingen, Germany
Dept.8288, WebSphere Portal Server Development
WSRP Standardization Technical Lead
Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888
Email: mailto:richard.jacob@de.ibm.com
To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/wsrp/members/leave_workgroup.php
.
To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/wsrp/members/leave_workgroup.php
.
To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsrp/members/leave_workgroup.php.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]