Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
In-Reply-To: <41E30F65.3090009@omnytex.com>
Sensitivity: 
Subject: Re: Proposal for a new Commons personalization package
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>,
        fzlists@omnytex.com
Message-ID: <200501110029.j0B0TlZk014800@igate.highmark.com>
From: daniel.vlad@highmark.com
Date: Mon, 10 Jan 2005 19:29:24 -0500
MIME-Version: 1.0
Content-Type: text/plain;
 charset=us-ascii
Content-Transfer-Encoding: 7bit


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