I would be happy to revive sirona @asf but dont think [monitoring] as just a few classes would bring enough value compare to a lambda not worthing any lib/dep in apps - just my opinion indeed.
For circuit breaker: geronimo safeguard can be interested in hosting that utility part and drop failsafe dependency. Maybe something to discuss in another thread. Le 20 mars 2018 23:27, "Otto Fowler" <ottobackwa...@gmail.com> a écrit : > Sirona is gone, it is a closed incubator project. Romain has forked it to > his own repo. > > > > On March 20, 2018 at 18:24:06, Gilles (gil...@harfang.homelinux.org) > wrote: > > On Tue, 20 Mar 2018 15:00:41 -0700, Otto Fowler wrote: > > If monitoring was started a new, and not re-viving the old > > monitoring? > > Can the feature be contributed to "Sirona"? Otto, are you > interested in this? > Does it make sense to have "Commons Monitoring" revived based > on part/all of "Sirona"? > Romain, are you interested in this? > What would be the scope/description of "Commons Monitoring"? > > Noting Romain's experience that the original "Commons" project > evolved into "Sirona", it would be strange to start from scratch > without a plan to not follow the same route again... > > Gilles > > > On March 20, 2018 at 17:56:44, Bruno P. Kinoshita ( > > brunodepau...@yahoo.com.br.invalid) wrote: > > > > I think StopWatch and CircuitBreakers could be moved together to the > > same > > component. However, a circuit breaker can be time-related, or not > > (e.g. a > > circuit breaker for memory size). So probably commons-timing could be > > a > > good place for StopWatch, but maybe not for circuit-breaker. But I > > think > > both could be under commons-monitoring perhaps? > > > > From: Otto Fowler <ottobackwa...@gmail.com> > > To: Romain Manni-Bucau <rmannibu...@gmail.com>; Commons Developers > > List < > > dev@commons.apache.org> > > Sent: Wednesday, 21 March 2018 10:30 AM > > Subject: Re: [DISCUSS] new component for timing? > > > > I would love to get this on track. I apologize if I have made it > > more > > confusing than it needs to be, > > I’m trying to be open to all the suggestions. > > > > If we assume that stack watch is worth ‘having’, then the question is > > where > > to put it. > > commons-monitoring / sirota seems to me to be a ‘complete’ solution > > as > > opposed to > > a set of or collection of like classes. > > > > Setting the community support / project aspect of sirota aside, it > > seems > > strange to put > > a separate class into a more complete and uniform system. Unless > > there is > > some generically > > useful set of timing utility classes that could be taken out of > > sirota to > > go into commons-????, > > along with things identified ( StopWatch?) out of commons lang and > > possibly > > other commons projects. > > > > commons-timing seems reasonable. Thoughts? > > > > > > > > On March 17, 2018 at 11:24:32, Romain Manni-Bucau > > (rmannibu...@gmail.com) > > wrote: > > > > Yes but consequence was a lack of community increase which is a > > killer for > > an incubator project on the long run. > > > > Le 17 mars 2018 15:19, "Gilles" <gil...@harfang.homelinux.org> a > > écrit : > > > >> On Sat, 17 Mar 2018 12:47:40 +0100, Romain Manni-Bucau wrote: > >> > >>> Le 17 mars 2018 11:49, "Gilles" <gil...@harfang.homelinux.org> a > >>> écrit : > >>> > >>> On Thu, 15 Mar 2018 15:13:39 +0100, Romain Manni-Bucau wrote: > >>> > >>> 2018-03-15 14:36 GMT+01:00 Otto Fowler <ottobackwa...@gmail.com>: > >>>> > >>>> If we can come to consensus on the way forward, I’ll be happy to > >>>> do the > >>>> > >>>>> work ( although I’ll need help of course ). > >>>>> I guess I’m the straw that broke the camel’s back then? ;) > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> On March 15, 2018 at 08:09:45, Gilles > >>>>> (gil...@harfang.homelinux.org) > >>>>> wrote: > >>>>> > >>>>> Hi. > >>>>> > >>>>> On Thu, 15 Mar 2018 03:52:58 -0700, Otto Fowler wrote: > >>>>> > I think bringing back commons-monitoring/sirota would only be > >>>>> > possible if > >>>>> > it were to be modular enough that you could bring in the ‘core’ > >>>>> > classes > >>>>> > without needing to bring in all of what sirota ended up being, > >>>>> which > >>>>> > was an > >>>>> > end to end solution. > >>>>> > >>>>> Isn't it possible? [I didn't look; Romain should tell whether he > >>>>> would be interested in taking that route.] > >>>>> > >>>>> > >>>>> Sirona was done modular, just the API, the in memory part, etc... > >>>> But this kind of impl needs way more just after so not sure it > >>>> does > > worth > >>>> splitting it to put it back altogether after. > >>>> > >>>> What is the rational to try to push a very small part @commons > >>>> instead > > of > >>>> creating a community @incubator with an E2E solution? This is what > >>>> I > > fail > >>>> to see. > >>>> My experience - coming exactly from here - tends to make me think > > commons > >>>> will not fit very long or will not bring enough value pretty > >>>> quickly > > but > >>>> that's just my opinion. > >>>> > >>>> > >>> Not "just" an opinion since you evoke Sirona's precursor as being > >>> the kind of component we'd reinstate. Unless we learn > >>> 1. why the precursor needed to become TLP, and > >>> 2. why the TLP didn't succeed, > >>> we'd go in circles. > >>> > >>> > >>> We failed at community@asf and pby communication/promotion levels I > >>> think. > >>> Other parts were successful (prod etc). > >>> > >>> > >> [It seems that part of your message went missing.] > >> > >> Lack of marketing skills should not entail failure, especially > >> not since communication is a transverse concern. > >> > >> Gilles > >> > >> Would it make sense that Sirona becomes (again?) "Commons > >> Monitoring"? > >>> Does the "StackWatck" (Otto's contribution that started this > >>> discussion) > >>> already exist in a Sirona module? If not, can it be done, so that > >>> usage > >>> is similar to what Otto had in mind? > >>> > >>> Regards, > >>> Gilles > >>> > >>> > >>> commons-monitoring or commons-timing seem to be the correct thing > >>>> > >>>>> > however, > >>>>> > but I would like to think that there would be more impetus > >>>>> > >>>>> I'm afraid that it's rather the lack of manpower. > >>>>> [And my inner conviction is that that state of things often > >>>>> led to rush to cramming more code into existing components, > >>>>> rather than "distribute" more uniformly according to subject > >>>>> matters. When scarce human resources ("community") disappear, > >>>>> cruft accumulates, sometimes up to stifle clean-up, maintenance, > >>>>> improvement, and even development.] > >>>>> > >>>>> > to do this than > >>>>> > thinking StackWatch is ‘too big’ for lang.time. > >>>>> > >>>>> It isn't any more than many other functionalities that were > >>>>> introduced but shouldn't have been. > >>>>> Depending on what the "Commons" PMC wants to favour ("code" > >>>>> *or* "community"?), the choice is between continuing with the > >>>>> accumulation, or back-pedaling through the creation of as > >>>>> many *real* components as they are developers willing to > >>>>> maintain them. > >>>>> > >>>>> > It really isn’t that complicated a thing. > >>>>> > >>>>> Sure. > >>>>> The issue is somewhere else. > >>>>> Note that, personally, I hadn't imagined that there would > >>>>> be an issue for regular developers of [Lang] (or I wouldn't > >>>>> have spent time reviewing the "details" ;-). > >>>>> But I of course agree that the question should be asked; the > >>>>> more so that, with [Math], we've a striking example of what > >>>>> awaits a library that lacks boundary checks and explicit > >>>>> road map. > >>>>> > >>>>> Regards, > >>>>> Gilles > >>>>> > >>>>> > On March 8, 2018 at 11:50:17, Gilles > >>>>> (gil...@harfang.homelinux.org) > >>>>> > wrote: > >>>>> > > >>>>> > On Thu, 08 Mar 2018 16:03:24 +0000, Gary Gregory wrote: > >>>>> >> -1 to "commons-misc". It feels to me like a copout and > >>>>> unfocused > >>>>> >> like > >>>>> >> SomethingUtils. > >>>>> >> We need a proper home. > >>>>> > > >>>>> > +1 > >>>>> > > >>>>> >> How about the idea of commons-measure. > >>>>> > > >>>>> > Just because the first feature would happen to be a timer? > >>>>> > What other content do you foresee? > >>>>> > > >>>>> >> Then there > >>>>> >> still the idea of resurrecting other Apache projects. Kind of > >>>>> going > >>>>> >> in > >>>>> >> circles... > >>>>> > > >>>>> > Indeed, IIRC the questions were asked (whether the feature > >>>>> could > >>>>> > be contributed to ex-Sirona and whether that project would be > >>>>> > repatriated to "Commons") but not answered (unless I'm > >>>>> mistaken)... > >>>>> > > >>>>> > Best, > >>>>> > Gilles > >>>>> > > >>>>> > > >>>>> >> Gary > >>>>> >> > >>>>> >> On Mar 8, 2018 08:58, "Otto Fowler" <ottobackwa...@gmail.com> > > wrote: > >>>>> >> > >>>>> >> So, could think about commons-misc or something? > >>>>> >> I don’t think we are going to come up with a perfect module > >>>>> for > >>>>> >> these > >>>>> >> things. > >>>>> >> > >>>>> >> Maybe the way it can work is: > >>>>> >> > >>>>> >> commons-misc exists. > >>>>> >> > >>>>> >> It is the landing place for things that seem to be outside the > > scope > >>>>> >> of > >>>>> >> commons-xxxx, but don’t justify > >>>>> >> a new module or sandbox effort. > >>>>> >> > >>>>> >> Things in misc can be reevaluated for inclusion in new modules > >>>>> at > >>>>> >> things > >>>>> >> go, and at that point @Depricated > >>>>> >> out of misc. > >>>>> >> > >>>>> >> ? > >>>>> >> > >>>>> >> > >>>>> >> > >>>>> >> On March 3, 2018 at 00:42:12, Matt Sicker (boa...@gmail.com) > >>>>> wrote: > >>>>> >> > >>>>> >> On 2 March 2018 at 13:31, Oliver Heger > >>>>> >> <oliver.he...@oliver-heger.de> > >>>>> >> wrote: > >>>>> >>> > >>>>> >>> One other suggestion: It was stated in the past that the > > concurrent > >>>>> >>> classes are also a bit out of scope for [lang], especially > >>>>> the > >>>>> >>> circuit > >>>>> >>> breaker implementations. Would it make sense to move those > >>>>> into a > >>>>> >>> new > >>>>> >>> module, and could this be a home for the watch classes, too? > >>>>> >>> > >>>>> >> > >>>>> >> Considering the amount of retry libraries there are out there, > >>>>> I > >>>>> >> think it > >>>>> >> makes perfect sense for circuit breaker libraries to be their > >>>>> own > >>>>> >> thing, > >>>>> >> too. See Hysterix for example. > >>>>> >> > >>>>> >> -- > >>>>> >> Matt Sicker <boa...@gmail.com> > >>>>> > >>>>> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org >