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
>
