[infinispan-dev] Defining new commands in modules

[Mircea Markus]

On 25 Oct 2010, at 12:41, Manik Surtani wrote:

> 
> On 11 Oct 2010, at 13:44, Mircea Markus wrote:
> 
>>> 
>>> PS: There is no JIRA for this.  If we like this approach and it works, I suggest we create a JIRA and implement it for 4.2.  The impl should be simple once we resolve the outstanding bits.
>> there is one actually: https://jira.jboss.org/browse/ISPN-256
>> I'll attache the patches to it.
>> Just to conclude, I've POC both approaches GenericCommand and ExtendingCommand, here are my thoughts on it:
>> - extending visitor
>> PROS:  ExtendingCommand is a better OO API, more strongly typed
>> CONS: it is harder for the user to understand; integrating custom serialization might be difficult(impossible at the time), also it will have to manage command uniques. 
> 
> Why is this hard for developers to understand?  Remember, these aren't *application* developers, but people *extending* Infinispan.  They already ought to have an in-depth knowledge of Infinispan.
> 
It's harder because they need to know more ISPN internals. 
> What do you mean by "command uniques"?
managing unique command IDs.
> 
>> - GenericCommand
>> CONS: 
>> - less OO API
>> - would require a "convention" for not "overusing" it. Overuse would be in client code though, not in ours
> 
> Client code may well be our code.  E.g., more modules that we ship.  -1 to a weakly typed API like this.  Conventions cannot be enforced, and IMO if something can be abused, then it will be abused.  :)
> 
Just give a hammer to a kid :) 
Even though this sort of extensions is not really for kids :)
>> PROS:
>> - easier for the user to understand and use
>> 	- no need for extra classes needed
>> 	- no understanding of how the interceptor chain internals work needed (for writing acceptVisitor). 
> Why would someone write a visitable command and not care about an interceptor that visits it?  Surely you would only write a visitable command if you *want* to visit it with an interceptor

>> 	- no understanding of how serialization works  is needed. Nor command uniques.
> 
> ?  What's so hard about this?  "implements Externabilzable" is the easy way, @Marshallable() a slightly more roundabout way for greater efficiency in marshalling.
what about managing unique command numbers?
> 
>> - easy streight-forward solutions
>> 
>> I would go for GenericCommand, but Extending approach works for me as well.
> 
> --
> Manik Surtani
> manik at jboss.org
> Lead, Infinispan
> Lead, JBoss Cache
> http://www.infinispan.org
> http://www.jbosscache.org
> 
> 
> 
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20101025/6bcdaaee/attachment-0001.html