i18n Revisited

[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

Re: i18n Revisited

["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.
>