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
[EMAIL PROTECTED] 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" <[EMAIL PROTECTED]> on 01/10/2005 06:27:33 PM
Please respond to "Jakarta Commons Developers List" <[email protected]>; Please respond to [EMAIL PROTECTED]
To: "Jakarta Commons Developers List" <[email protected]> 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
[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]
