I want to add that I appreciate the effort you have put into this code. You are clearly investing a significant amount of time in PivotPad, and I'm looking forward to seeing the result (if you are willing to share it).
The thing I am struggling with is what, to me, seems like a relatively high level of complexity. Pivot features are meant to be as easy to understand and use as possible. That means that they should also be easy to describe, so that developers can readily grasp the details and become productive quickly. So far, I haven't found that to be the case with some of the approaches you have suggested - I don't immediately "get it". We don't want developers to have to struggle to understand a concept. It is possible that I'm just being unusually dense, or that you may be able to describe the features in simpler terms such that they are more easily digested. Or, these features may simply be too complex for inclusion in the framework. I definitely do not want to discourage you from continuing to submit code, patches, etc. but just want to suggest that simplicity is key in Pivot. Any changes made to the platform should have a clear benefit and should fit in cleanly with the existing structures and APIs. If that's not the case, it doesn't necessarily mean that the code isn't useful or valuable - it just means that it probably doesn't belong in the platform. Thanks again. Hope this helps. Greg On Jun 20, 2010, at 10:38 AM, Greg Brown wrote: > Need to see usage examples. It is difficult to understand what these classes > are meant to do without seeing how they are supposed to be applied. The > "design doc" will probably help here. > > Either way, I don't think we'd want to include support for weak references, > and I'm not sure we need to do anything special to increase the granularity > of the topic subscriptions. A topic is just a class - it is up to the app to > decide how coarsely or finely to define those classes to meet the needs of > the application. > > On Jun 20, 2010, at 10:08 AM, aappddeevv wrote: > >> Here's the code that I am using. Not all the corner cases have tested out >> yet, but this is the general idea. >> >> The one thing that could become a concern about the messaging in the >> application context is how to filter messages efficiently on more than just >> class type-which is large grained filtering. But its not a problem now so >> fine-grained filtering can be in a message listener subclass or in the >> annotated method itself. >> >> >> >> -----Original Message----- >> From: Greg Brown (JIRA) [mailto:[email protected]] >> Sent: Sunday, June 20, 2010 9:45 AM >> To: [email protected] >> Subject: [jira] Commented: (PIVOT-535) Add a @MessageListener annotation and >> an annotation processor for application context message listener >> >> >> [ >> https://issues.apache.org/jira/browse/PIVOT-535?page=com.atlassian.jira.plug >> in.system.issuetabpanels:comment-tabpanel&focusedCommentId=12880636#action_1 >> 2880636 ] >> >> Greg Brown commented on PIVOT-535: >> ---------------------------------- >> >> Agreed re: weak listeners - not a good idea. >> >> Appddevv, >> >> Can you provide a description of how these new features would work, >> including code examples? I'd also like to understand how the annotation >> processing would work and where it would live (basically, I am looking for a >> mini "design spec" for what you are proposing). >> >> Thanks, >> Greg >> >> >> >>> Add a @MessageListener annotation and an annotation processor for >> application context message listener >>> >> ---------------------------------------------------------------------------- >> -------------------------- >>> >>> Key: PIVOT-535 >>> URL: https://issues.apache.org/jira/browse/PIVOT-535 >>> Project: Pivot >>> Issue Type: Improvement >>> Reporter: Appddevvv >>> >>> Add a message listener annotation and a static method for annotation >> processing to automatically enroll instance/methods in application message >> handling. >>> I have the classes that I can submit as a starting point. They allow weak >> and strong references as well as optional request-reply semantics. >> >> -- >> This message is automatically generated by JIRA. >> - >> You can reply to this email to add a comment to the issue online. >> <message-listener.zip> >
