portletspec3
  1. portletspec3
  2. PORTLETSPEC3-29

P3PUserInfos may need clarification and could be outdated in some areas

    Details

      Description

      First of all there seems to be an issue and missing documentation of the PortletRequest.P3PUserInfos enum.

      Aside from similar observations for containers like Liferay this was discussed and answered for WebSphere Portal in late 2008
      https://www.ibm.com/developerworks/community/forums/html/topic?id=77777777-0000-0000-0000-000014161216

      IBM support engineer Jim Barnes replied:
      >I talked with dev on this and it seems this is a errata in the spec and the toString must be called, and this will be pushed in the next >errata for the spec
      >
      >Jim

      Specifying and documenting this properly is the minimum requirement I'd see we should cover in this JSR.

      Beside I'd like to raise the question, to what extent the enum attributes are still relevant.
      Fields like: USER_HOMEINFO_TELECOM_PAGER_NUMBER
      while other obvious ones like
      USER_HOMEINFO_ONLINE_TWITTER (or _FACEBOOK, etc.) are clearly missing in today's world.

      The EG of JSR-351, Identity Management for Java discussed similar challenges, including the problem of enums and their limited extensibility as well as an often changing set of Identity Attributes that this enum and the Portlet 2.0 spec hoped to cover somehow.
      I may propose synergies with JSR-351 in the "extensions" component, but wanted to mention it here, too. Potentially an area where 351 could help, but at the very least the enum vs. toString() problem should be resolved and the enum better documented. Where appropriate some attributes may be added others at least deprecated.

        Activity

        Hide
        andre.hagemeier added a comment -

        I wonder whether adding more fields would be the right way to go. From my point of view, custom data is retrieved by other means. I assume vendors provide APIs to access user data, like WebSPhere Portal does with PUMA. These APIs would be more powerful and flexible then any enum retrieved from the portlet request could ever be.
        In the portlet4.0 spec, people might wonder, why we added twitter and facebook, because other they ceased to exist. I think, if any, the most important user features should be part of the enum (given name, last name, email, phone, birthday, etc) and the rest should be deprecated.

        Show
        andre.hagemeier added a comment - I wonder whether adding more fields would be the right way to go. From my point of view, custom data is retrieved by other means. I assume vendors provide APIs to access user data, like WebSPhere Portal does with PUMA. These APIs would be more powerful and flexible then any enum retrieved from the portlet request could ever be. In the portlet4.0 spec, people might wonder, why we added twitter and facebook, because other they ceased to exist. I think, if any, the most important user features should be part of the enum (given name, last name, email, phone, birthday, etc) and the rest should be deprecated.
        Hide
        msnicklous added a comment -

        I think we should keep this one open for now and discuss this issue when we talk about device support.

        Show
        msnicklous added a comment - I think we should keep this one open for now and discuss this issue when we talk about device support.

          People

          • Assignee:
            Unassigned
            Reporter:
            keilw
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated: