commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Frank W. Zammetti" <fzli...@omnytex.com>
Subject Re: Proposal for a new Commons personalization package
Date Tue, 11 Jan 2005 01:11:10 GMT
Daniel,

Uhh... umm... what?!?

I am sincerely confused why you would have found any of that offensive. 
  The only thing I even *remotely* think could be is the politics 
comment, and that was followed by a smiley.  Even if it wasn't, I 
sincerely doubt that would be offensive to anyone, certainly I don't 
think it should be.

I really don't see where anything I wrote would be considered 
inappropriate by anyone, and I'd certainly like the opportunity to 
defend myself if anyone disagrees with that statement.

About my name on the list, I just want to clarify that comment... I was 
only surprised because while I said I'd be willing to help as much as 
time allows, I didn't see a reply from you (I could have missed it, 
sorry if that's the case), so I didn't anticipate being listed.  That's 
all, nothing sinister there.

-- 
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com


daniel.vlad@highmark.com wrote:
> 
> 
> 
> Frank,
> 
> I do not agree with your comments, and I don't think they are appropriate.
> I can even see why this list will find them offensive. I added your name to
> the initial list of developers (not committers) because you asked to, but
> your comments can jeopardize the entire proposal.
> 
> Daniel Vlad
> 
> 
> 
> 
> 
> "Frank W. Zammetti" <fzlists@omnytex.com> on 01/10/2005 06:27:33 PM
> 
> Please respond to "Jakarta Commons Developers List"
>        <commons-dev@jakarta.apache.org>; Please respond to
>        fzlists@omnytex.com
> 
> 
> 
> To:    "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
> cc:
> Subject:    Re: Proposal for a new Commons personalization package
> 
> Wow, my name's on it!  Didn't actually expect that :)
> 
> Hey, even if they don't accept it as a Commons project, just open it up
> on SF.  Might almost be better there to be honest.  If nothing else
> you'd be in complete control of it yourself, no politics to worry about,
> aside from those you create yourself of course :)
> 
> Have you spent any time putting together some diagrams to try and
> explain what you envision?  That certainly couldn't hurt get the "big
> picture" across.  A picture is worth a thousand words, and all that jazz :)
> 
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
> 
> daniel.vlad@highmark.com wrote:
> 
>>
>>
>>I have updated the proposal (see below) to include the suggestions
> 
> received
> 
>>and to detail out some of the ambiguous parts of the original proposal.
>>It might be a good idea to rename the package to Personalization Rules.
> 
> It
> 
>>better spells out what we are trying to accomplish, and at the same time
> 
> it
> 
>>will probably fit better under the Commons Project.
>>I believe that the Commons Project will be a good fit, at least
> 
> initially.
> 
>>Later, we can always decide to move it somewhere else if necessary, but I
>>am open to suggestions.
>>
>>Let me know if you have any additional questions or comments in regard to
>>this proposal. I wanted to thank you for your very valuable feedback and
>>ideas, and I hope you will decide to support it.
>>
>>Regards,
>>Daniel Vlad
>>
>>
>>Proposal for a new Commons Personalization Rules package
>>
>>(0)  rationale
>>
>>Personalization is a major requirement for all types of Java applications
>>(web, portal, Swing, applets, stand-alone clients, wireless applications,
>>etc.)
>>There is no industry standard solution for personalizing Java
> 
> applications
> 
>>in general. It is common for developers to implement personalization
>>requirements by intermixing personalization logic with application code
> 
> or
> 
>>even hard-coding personalization requirements directly in JSP.
>>
>>Vendor personalization solutions target only portal development and they
>>are restricted to applications running inside a portlet container. As a
>>result, portal personalization solutions are not appropriate for
>>stand-alone web applications or plain Java applications.
>>
>>A set of lightweight, technology-independent, reusable personalization
>>components can provide significant benefits to application development:
>>-  encapsulate personalization logic code and decouple this code from the
>>rest of the application, thus simplifying application development and
>>maintenance.
>>-  centralize the management of the personalization rules, ensuring
>>application consistency.
>>-  improve the performance of the application by caching the outcomes of
>>the personalization decisions.
>>
>>JSR 168 (Portlet) specification does not define a common approach for
>>encapsulating personalization logic and making personalization decisions.
>>The specification provides per-user portlet preferences and allows
> 
> vendors
> 
>>to plug-in their own personalization engines to make decisions based on
>>these preferences. Thus, a set of components to manage personalization
>>decisions will even be beneficial to portlet developers.
>>
>>(1)  scope of the package
>>
>>The package will create a set of reusable components to encapsulate the
>>personalization logic in the application and to decouple these rules from
>>the rest of the application.
>>
>>(1.5)  interaction with other packages
>>
>>The package will use the following external packages:
>>Commons Digester - to parse the personalization XML file
>>Commons Logging - for logging
>>
>>(2)  identify the initial source for the package
>>
>>The initial codebase will be contributed by Daniel H. Vlad, and it is
> 
> based
> 
>>on the article "Personalize Your Web Applications", authored by Daniel
> 
> and
> 
>>published as a Cover Story in Java Developer's Journal, December 2004,
>>pages 34-40.
>>
>>Article URL: http://www.sys-con.com/story/?storyid=47357&DE=1
>>Pdf download: http://pdf.sys-con.com/Java/JDJDecember2004.pdf
>>
>>Initial Design:
>>
>>The main abstraction in this package is a PersonalizationRule. A rule
>>encapsulates logic needed to make a personalization decision. In order to
>>make a decision, a rule needs user data and preferences, as well as rule
>>configuration parameters.
>>
>>User data and preferences:
>>- user preferences will be accessed using the Preferences API.
>>- user data will be fed to a Rule through an interface that can be
>>implemented to hold data coming from any external user repository, such
> 
> as
> 
>>LDAP. In particular this design pattern should allow a rule to be
>>configured using the Portlet Preferences, to make personalization
>>components compatible with JSR 168 API.
>>- the design from the JDJ article should be updated to remove the
>>dependency on the Servlet API and to make the personalization components
>>technology-independent.
>>
>>Rule configuration:
>>- rules will be declared and configured in an XML file. For flexibility,
>>the configuration file should allow each rule to specify the
> 
> implementation
> 
>>class declaratively.
>>
>>Additional features:
>>- composite rules, or rules created by aggregating other rules using
>>Boolean operators (AND, OR, etc.). Composite rules should be declared in
>>XML format. Example: If user is a Manager AND belongs to Department X.
>>- a set of commonly used rules should be provided with the code
>>distribution. For example, rules based on security roles (see JDJ article
>>example), rules that check if a user attribute/preference matches some
>>data, etc.
>>- content rules, rules that dynamically decide the content that should be
>>displayed to users. This can be accomplished, for example, by
> 
> categorizing
> 
>>users in groups using grouping criteria and mapping these user groups on
>>content items using an XML mapping file.
>>- add caching to improve performance.
>>
>>The initial design will be updated/enhanced/improved as necessary.
>>
>>(2.1)  identify the base name for the package
>>org.apache.commons.personalization
>>(2.2)  identify the coding conventions for this package
>>Sun coding conventions
>>
>>(3)  identify any Jakarta-Commons resources to be created
>>(3.1)  mailing list
>>Until traffic justifies, the package will use the Jakarta-Commons list
> 
> for
> 
>>communications.
>>(3.2)  CVS repositories
>>For the time being, the package will use a root branch of the
>>Jakarta-Commons CVS.
>>(3.3)  Bugzilla
>>The package should be listed as a component of under the Jakarta-Commons
>>Bugzilla entry.
>>
>>(4)  identify the initial set of committers to be listed in the Status
>>File.
>>Daniel H. Vlad
>>other committers TBD
>>
>>Initial group of developers:
>>Daniel H. Vlad
>>Karan Malhi
>>Frank W. Zammetti
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>>
>>
>>
>>
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 
> 
> 
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 
> 
> 
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message