commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <>
Subject Re: [CHAIN] Chain 2.0
Date Wed, 24 Apr 2013 17:49:24 GMT
On 24 April 2013 14:48, Steve Westwood <> wrote:

> Christian Trimble recently sent to the list details of the XChain project
> (see<> and<
>> )
> and pondered on whether aspects of this could be accommodated in
> commons-chain.
>  There has not been any response to this email (apologies to Christian),
> but it
> does raise an interesting question about where does the wider community
> want
> commons-chain to go.
> Simone Tripodi summarised his view of the 2.0 release recently, with it
> consisting of:
> * Support for same features of 1.x
> * Increased modularisation
> * Use of generics
> * A Fluent API (EDSL)
> * Web support
> * Increase number of supported formats  for external chain configuration
> (add
> JSON, YAML etc.. to the current support for XML)
> As things stand, all of the above have been implemented apart from the
> support
> for additional files formats (defined in CHAIN-76), although more testing
> and
> samples are required.
> Christians links point to an interesting, if very specific use of chains :
> XChain fuses the commons-chain  and JXPath projects, and there may be
> merit in
> the creation of a module/component to accommodate this in chains. Whether
> this
> should be in a 2.0 release needs to be discussed, however, I would favour
> the
> following happening with Chain:
> 1. Move CHAIN-76 to another release (2.1?) – I am not aware of any great
> demand
> for this functionality
> 2. Make a 2.0 release candidate of the SVN trunk as is and move towards a
> substantial test phase.
> This would have the merit of ensuring much of the recent great work from
> Simone
> and others goes out into the wider world and hopefully kick-starts
> interest in
> commons-chain. Of course, if the response is minimal, then perhaps we
> should
> reduce effort in commons-chain as is, although this is a wider community
> decision.
> Look forward to hearing opinions on this.
I have no particular view on the API of Chain2, but I do think it's worth
ensuring that the API is as correct as possible.
Changes to the API often require incompatible code, and that should be
avoided as far as possible.

I note that there is a separate api source tree - if this is the only
public API, then that is great as it potentially allows changes to any
other part of the code without breaking the official API. However, it would
need to be made very clear to end-users that if they use anything else then
there are no guarantees that their code will continue to work or compile.
For example, if one uses a class from the sun.* package, one knows that it
is a hack at best.

> Steve Westwood

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message