Hi, OK. It looks like we can have multiple usages of the JSON ticket registry : from a simple one to a more advanced one. Would you mind creating a JIRA to track that request for 4.1 ? Thanks. Best regards, Jérôme
2013/10/9 Marvin S. Addison <[email protected]> > I think it makes sense as JSON has become a widely adopted standard. We >> should certainly wait for 4.1 though. >> > > That timeline seems reasonable. > > At first, I thought you were talking about the Unicon extension : >> https://github.com/Unicon/cas-**addons/wiki/Configuring%** >> 20JSON%20Service%20Registry<https://github.com/Unicon/cas-addons/wiki/Configuring%20JSON%20Service%20Registry> >> . >> It seems to be the same idea, isn't it. >> > > Similar idea, different requirements. I reviewed the Unicon component and > found it lacking the following features I needed: > > - Does not keep filesystem changes in sync with in-memory registry. > - Inadequate file locking. > > The Unicon component is in no way deficient for lack of those features; it > was simply driven by different requirements (IIRC extensible, ad hoc > service attributes). My use case required storing data on a shared > filesystem and concurrent access from multiple hosts. I'd be happy to > consider consolidating features for the component that will go into CAS. > > M > > -- > You are currently subscribed to [email protected] as: > [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/**display/JSG/cas-dev<http://www.ja-sig.org/wiki/display/JSG/cas-dev> > -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
