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(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev