Stephen,
I realized from the beginning that not being a committer lowers the
chances for acceptance. However, I was hoping that the proposal will be
judged for its value, without prejudice. If you or another existing
committer is willing to support this project I can enter his name in the
committers section. If required, I can remove mine. I can contribute as a
simple developer without committing rights.
Thanks,
Daniel Vlad
"Stephen Colebourne" <[EMAIL PROTECTED]> on 01/10/2005 06:44:47
PM
Please respond to "Jakarta Commons Developers List"
<commons-dev@jakarta.apache.org>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>,
[EMAIL PROTECTED]
cc:
Subject: Re: Proposal for a new Commons personalization package
Commons is a weird place in that it is a bit like a club sometimes. You
generally need to already be an Apache/Jakarta committer somewhere (not
necessarily commons) to get a new project started.
SF is often the solution to this, although it has the disadvantage of less
publicity and immediate feedback. Even if its just to work out the initial
codebase, and then to try to get some key people from jakarta interested
(eg
portals people).
Stephen
----- Original Message ----- >
> 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
>
> [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>>
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
