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]
