commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karan Malhi <karan.ma...@gmail.com>
Subject Re: Proposal for a new Commons personalization package
Date Tue, 11 Jan 2005 01:24:37 GMT
Even i feel that this proposal should be judged on value its going to
bring in to the Java community. I am pretty sure, if the committers
look at this proposal, then we will definitely get something started.
I think the committers should come forward and add some more thoughts
to it. Looking at the kind of experience the committers have and the
wonderful projects they have given to the java community, their
experience in shaping this proposal is also very important. Is there
something else which the committers need for this project to be part
of commons?, if there is , then please give your valuable thoughts to
this proposal.

Regards

Karan Malhi


On Mon, 10 Jan 2005 20:11:10 -0500, Frank W. Zammetti
<fzlists@omnytex.com> wrote:
> 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
> 
> 


-- 
Karan Malhi

---------------------------------------------------------------------
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