You are viewing a plain text version of this content. The canonical link for it is here.
Posted to pluto-dev@portals.apache.org by "David H. DeWolf" <dd...@apache.org> on 2004/03/02 16:04:15 UTC
[DRAFT] Pluto Intent Documentation
All,
It was suggested that we document our intent for developing pluto in
order to clarify our position on making enhancements which are above and
beyond the specification. I have attempted to put into a single
document the things that we have discussed in the past. Attached is a
draft of that document.
Once this document is reviewed and input from others is received, I will
put together a proposal which we can vote on. Once a document is
accepted, we should publish it to the pluto website. Please send your
comments and suggestions.
David
Re: [DRAFT] Pluto Intent Documentation
Posted by Stephan Hesmer <sh...@apache.org>.
I agree, very nice document David.
Thanks for putting this together.
I also agree that this should be published on our website.
Stephan
Stefan Hepper wrote:
> Thanks for starting this David, looks really good!
>
> Please see my comments below.
>
> Stefan
>
>
> David H. DeWolf wrote:
>
>> All,
>>
>> It was suggested that we document our intent for developing pluto in
>> order to clarify our position on making enhancements which are above
>> and beyond the specification. I have attempted to put into a single
>> document the things that we have discussed in the past. Attached is a
>> draft of that document.
>>
>> Once this document is reviewed and input from others is received, I
>> will put together a proposal which we can vote on. Once a document is
>> accepted, we should publish it to the pluto website. Please send your
>> comments and suggestions.
>>
>> David
>>
>>
>> ------------------------------------------------------------------------
>>
>> #### DRAFT ####
>>
>> The Pluto Portlet Container is the Reference Implementation of the
>> JSR-168 Portlet Specification.
>
>
> I would rephrase this to:
> The Pluto Portlet Container is the Reference Implementation of the Java
> Portlet Specification.
>
> to avoid the JSR number, as for the V1.1 of the portlet spec we will get
> a new JSR number.
>
>> As such, Pluto offers the development community a reference for
>> interpretation of
>> the specification, portlet developers a container with which JSR-168
>> compliant portlets can be tested, and portal developers
>
>
> remove JSR 168 here also
>
>> a compliant container with which they can integrate.
>> The following document attempts to clarify the development priorities
>> of Jakarta Pluto Project.
>>
>> The primary concern of the pluto community is to
>> ensure that the Pluto Container maintains compatibility with
>> the JSR-168 Specification. Enhancements and bug fixes should
>
>
> "most current Java Portlet Specification" instead of JSR 168
>
>> be completed in a manner in which compatibility is maintained.
>>
>> It is the responsibility of the pluto development team to ensure that
>> no ambiguity is introduced into the reference implementation. No
>> enhancements should be implemented which
>> introduce questions about the specification.
>>
>
> I like that part ;-)
>
>> It is desirable for Pluto to become a robust and easy to use
>> portlet container. This will facilitate its wider acceptance
>> and usage in the community. In order to accomplish these goals,
>> it is assumed that enhancements which are above and beyond the
>> specification will be introduced. These enhancements may be
>> integrated with Pluto as long as they do not compromise the integrity
>> of the reference implementation as described above.
>> Furthermore, functionality which is clearly beyond the scope
>> of the specification should be documented as such.
>>
>
> How about having a specific package under which all enhancements are
> collected in order to make it clear what the required parts are?
> I would also like to add something like:
> "The Pluto container needs to remain fully specification compliant and
> in a working state when these enhancements are not present."
> Just to allow people to use the minimal pluto without any enhancements.
>
>
>
>> Finally, while the pluto project contains several subprojects, it is
>> important to realize that the container itself is the most important
>> aspect of the project. It, in an of itself, is
>> the JSR-168 reference implementation. The portalDriver, testsuite,
>
>
> remove JSR 168
>
>> and deployer exist to simplfy the use and testing of the container. As
>> such, any significant enhancements to these components (most
>> especially the portal driver) should be scrutinized before
>> implementation, as most likely, it is
>> outside the scope of the pluto project and belong in a portal
>> implementation.
>>
>
>
>
>
>
Re: [DRAFT] Pluto Intent Documentation
Posted by Stefan Hepper <st...@hursley.ibm.com>.
Thanks for starting this David, looks really good!
Please see my comments below.
Stefan
David H. DeWolf wrote:
> All,
>
> It was suggested that we document our intent for developing pluto in
> order to clarify our position on making enhancements which are above and
> beyond the specification. I have attempted to put into a single
> document the things that we have discussed in the past. Attached is a
> draft of that document.
>
> Once this document is reviewed and input from others is received, I will
> put together a proposal which we can vote on. Once a document is
> accepted, we should publish it to the pluto website. Please send your
> comments and suggestions.
>
> David
>
>
> ------------------------------------------------------------------------
>
> #### DRAFT ####
>
> The Pluto Portlet Container is the Reference Implementation of
> the JSR-168 Portlet Specification.
I would rephrase this to:
The Pluto Portlet Container is the Reference Implementation of the Java
Portlet Specification.
to avoid the JSR number, as for the V1.1 of the portlet spec we will get
a new JSR number.
> As such, Pluto offers
> the development community a reference for interpretation of
> the specification, portlet developers a container with which
> JSR-168 compliant portlets can be tested, and portal developers
remove JSR 168 here also
> a compliant container with which they can integrate.
>
> The following document attempts to clarify the development
> priorities of Jakarta Pluto Project.
>
> The primary concern of the pluto community is to
> ensure that the Pluto Container maintains compatibility with
> the JSR-168 Specification. Enhancements and bug fixes should
"most current Java Portlet Specification" instead of JSR 168
> be completed in a manner in which compatibility is maintained.
>
> It is the responsibility of the pluto development team to
> ensure that no ambiguity is introduced into the reference
> implementation. No enhancements should be implemented which
> introduce questions about the specification.
>
I like that part ;-)
> It is desirable for Pluto to become a robust and easy to use
> portlet container. This will facilitate its wider acceptance
> and usage in the community. In order to accomplish these goals,
> it is assumed that enhancements which are above and beyond the
> specification will be introduced. These enhancements may be
> integrated with Pluto as long as they do not compromise the
> integrity of the reference implementation as described above.
> Furthermore, functionality which is clearly beyond the scope
> of the specification should be documented as such.
>
How about having a specific package under which all enhancements are
collected in order to make it clear what the required parts are?
I would also like to add something like:
"The Pluto container needs to remain fully specification compliant and
in a working state when these enhancements are not present."
Just to allow people to use the minimal pluto without any enhancements.
> Finally, while the pluto project contains several subprojects,
> it is important to realize that the container itself is the
> most important aspect of the project. It, in an of itself, is
> the JSR-168 reference implementation. The portalDriver, testsuite,
remove JSR 168
> and deployer exist to simplfy the use and testing of the
> container. As such, any significant enhancements to these
> components (most especially the portal driver) should be
> scrutinized before implementation, as most likely, it is
> outside the scope of the pluto project and belong in a portal
> implementation.
>
Re: i18n Revisited
Posted by "David H. DeWolf" <dd...@apache.org>.
Michael,
Thanks for your patience and persistence! I know for myself, the fact
that this patch hasn't been committed isn't a reflection on the patch
itself, but rather a reflection on our lack of direction concerning
committing patches that are outside of "bug fixes". As you have seen,
the purpose of the intent document is to come to a consensus so that we
can begin to process these enhancements. In that regard, please realize
that this document is simply a draft that one committer has put out to
the community for feedback. To that point, it does seem like we are
quickly approaching a consens (Yay!).
As for the specifics of your patch, I personally have no problem
incorporating it. In my opinion you have adequately defined a true need
which needs to be met no matter what decision is made regarding the
pluto intent document. As you point out, the patch not only increases
the reach of our community, but also does nothing to compromise the
standing of pluto as the RI. It is true that, based on the proposed
intent document, this is the type of enhancement which would need to be
"scrutinized", however, I feel as though this is also a good example of
the type of "portalDriver" enhancement that should be allowed.
Nick has volunteered to apply the patch, as far as I'm concerned -- GO
FOR IT!
David
Michael Westbay wrote:
> The pluto-intent.txt document appears to be the closest thing to
> feedback regarding my internationalization enabling patch:
>
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26586
>
> that's come up lately. Is this an indirect answer to my appeals to have
> it "scrutinized"?
>
> The last paragraph of pluto-intent.txt appears to say that i18n should
> only be done in a "real" portal implementation:
>
>> [...] It, in an of itself, is
>> the JSR-168 reference implementation. The portalDriver, testsuite,
>> and deployer exist to simplfy the use and testing of the container. As
>> such, any significant enhancements to these components (most
>> especially the portal driver) should be scrutinized before
>> implementation, as most likely, it is
>> outside the scope of the pluto project and belong in a portal
>> implementation.
>
>
> Still, based on that alone, the (or any) i18n patch cannot be
> automatically excluded before a period of scrutinization has been given.
> So I welcome a review of the patch and any reason against its inclusion.
>
> The reason for including it are plentiful, spelled out very well in the
> pluto-intent.txt document:
>
> 1. "... Pluto offers ... portlet developers a container with which
> [Java Portlet Specification] compliant portlets can be tested,
> ..."
>
> As it stands, only Pluto only offers this functionality to portal
> developers in North America or those who are limited to the
> iso-8859-1 character set. My proposed patch widens the possible
> developer community to include the world, Asian languages in
> particular.
>
> 2. "... ensure that the Pluto Container maintains compatibility with
> the [Java Portlet] Specification. Enhancements and bug fixes
> should be completed in a manner in which compatibility is
> maintained."
>
> The patch introduces nothing that will break compatibility, nor
> does it introduce anything that may complicate the creation and/or
> deployment of portlets into a Pluto Container. It simply allows
> the Pluto Driver to output in character sets other than iso-8859-1
> if the developer using it for testing so desires.
>
> 3. "It is the responsibility of the pluto development team to ensure
> that no ambiguity is introduced into the reference implementation.
> No enhancements should be implemented which introduce questions
> about the specification."
>
> The patch does nothing to change any specification. No ambiguity
> is introduced. "Real" portal drivers will be free to handle
> the character sets used in output streams in what ever way they
> feel is appropriate as they wouldn't be using the Pluto Driver
> anyway.
>
> In fact, by applying this patch, portlet developers will be less
> likely to try to find work arounds for getting a specific encoding
> output while testing with Pluto, as the driver is outside the
> scope and control of the portlet writer. The first thing I tried
> when attempting to output Kanji was to set the content type of
> the response. By not allowing the output stream character set to
> be set, it is creating more confusion on the part of portlet dev-
> elopers. This functionality actually will clear up the ambiguity
> of where the control of output stream character set belongs - in
> the Portal Driver.
>
> 4. "It is desirable for Pluto to become a robust and easy to use
> portlet container. This will facilitate its wider acceptance
> and usage in the community."
>
> This patch broadens the "community" to include the rest of the
> world, Asian developers in particular.
>
> 5. "... functionality which is clearly beyond the scope of the
> specification should be documented as such."
>
> If the documentation included in the bugzilla report isn't
> enough, I'll be more than happy to write more on the subject in
> which ever xdoc document you desire.
>
> Finally, it is difficult to convince my co-workers to apply a patch to
> Pluto (or any system) just to output Japanese. They see it as a
> weakness in the overall design of the system, despite my pointing out
> that it has nothing to do with the actual development of portlets beyond
> testing them. If you are truly concerned with building a global
> community of portlet developers with Pluto, then it must work with Asian
> languages out of the box (or by simply setting a property).
>
> In conclusion, the pluto-intent.txt overwhelmingly supports the
> inclusion of the (or an) internationalization patch. Please, go over
> the proposed patch with a fine tooth comb. Scrutinize and optimize it.
> But at the very least, please do something so that Pluto 1.0 will
> support character sets beyond iso-8859-1 for developers out of the box.
> Or present a clear explanation as to why i18n is outside the scope of
> Pluto's intent.
>
i18n Revisited
Posted by Michael Westbay <we...@users.sourceforge.net>.
The pluto-intent.txt document appears to be the closest thing to
feedback regarding my internationalization enabling patch:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26586
that's come up lately. Is this an indirect answer to my appeals to have
it "scrutinized"?
The last paragraph of pluto-intent.txt appears to say that i18n should
only be done in a "real" portal implementation:
> [...] It, in an of itself, is
> the JSR-168 reference implementation. The portalDriver, testsuite,
> and deployer exist to simplfy the use and testing of the
> container. As such, any significant enhancements to these
> components (most especially the portal driver) should be
> scrutinized before implementation, as most likely, it is
> outside the scope of the pluto project and belong in a portal
> implementation.
Still, based on that alone, the (or any) i18n patch cannot be
automatically excluded before a period of scrutinization has been given.
So I welcome a review of the patch and any reason against its inclusion.
The reason for including it are plentiful, spelled out very well in the
pluto-intent.txt document:
1. "... Pluto offers ... portlet developers a container with which
[Java Portlet Specification] compliant portlets can be tested,
..."
As it stands, only Pluto only offers this functionality to portal
developers in North America or those who are limited to the
iso-8859-1 character set. My proposed patch widens the possible
developer community to include the world, Asian languages in
particular.
2. "... ensure that the Pluto Container maintains compatibility with
the [Java Portlet] Specification. Enhancements and bug fixes
should be completed in a manner in which compatibility is
maintained."
The patch introduces nothing that will break compatibility, nor
does it introduce anything that may complicate the creation and/or
deployment of portlets into a Pluto Container. It simply allows
the Pluto Driver to output in character sets other than iso-8859-1
if the developer using it for testing so desires.
3. "It is the responsibility of the pluto development team to ensure
that no ambiguity is introduced into the reference implementation.
No enhancements should be implemented which introduce questions
about the specification."
The patch does nothing to change any specification. No ambiguity
is introduced. "Real" portal drivers will be free to handle
the character sets used in output streams in what ever way they
feel is appropriate as they wouldn't be using the Pluto Driver
anyway.
In fact, by applying this patch, portlet developers will be less
likely to try to find work arounds for getting a specific encoding
output while testing with Pluto, as the driver is outside the
scope and control of the portlet writer. The first thing I tried
when attempting to output Kanji was to set the content type of
the response. By not allowing the output stream character set to
be set, it is creating more confusion on the part of portlet dev-
elopers. This functionality actually will clear up the ambiguity
of where the control of output stream character set belongs - in
the Portal Driver.
4. "It is desirable for Pluto to become a robust and easy to use
portlet container. This will facilitate its wider acceptance
and usage in the community."
This patch broadens the "community" to include the rest of the
world, Asian developers in particular.
5. "... functionality which is clearly beyond the scope of the
specification should be documented as such."
If the documentation included in the bugzilla report isn't
enough, I'll be more than happy to write more on the subject in
which ever xdoc document you desire.
Finally, it is difficult to convince my co-workers to apply a patch to
Pluto (or any system) just to output Japanese. They see it as a
weakness in the overall design of the system, despite my pointing out
that it has nothing to do with the actual development of portlets beyond
testing them. If you are truly concerned with building a global
community of portlet developers with Pluto, then it must work with Asian
languages out of the box (or by simply setting a property).
In conclusion, the pluto-intent.txt overwhelmingly supports the
inclusion of the (or an) internationalization patch. Please, go over
the proposed patch with a fine tooth comb. Scrutinize and optimize it.
But at the very least, please do something so that Pluto 1.0 will
support character sets beyond iso-8859-1 for developers out of the box.
Or present a clear explanation as to why i18n is outside the scope of
Pluto's intent.
--
Michael Westbay