[DISCUSS] new component for timing?

classic Classic list List threaded Threaded
46 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] new component for timing?

Gilles Sadowski
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" <[hidden email]> 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 ([hidden email]) wrote:
>
> On 2 March 2018 at 13:31, Oliver Heger <[hidden email]>
> 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 <[hidden email]>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] new component for timing?

Otto Fowler
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.

commons-monitoring or commons-timing seem to be the correct thing however,
but I would like to think that there would be more impetus to do this than
thinking StackWatch is ‘too big’ for lang.time.

It really isn’t that complicated a thing.


On March 8, 2018 at 11:50:17, Gilles ([hidden email]) 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" <[hidden email]> 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 ([hidden email]) wrote:
>
> On 2 March 2018 at 13:31, Oliver Heger <[hidden email]>
> 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 <[hidden email]>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] new component for timing?

Gilles Sadowski
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.]

> 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 ([hidden email])
> 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" <[hidden email]> 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 ([hidden email]) wrote:
>>
>> On 2 March 2018 at 13:31, Oliver Heger
>> <[hidden email]>
>> 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 <[hidden email]>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] new component for timing?

Otto Fowler
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 ([hidden email]) 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.]

> 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 ([hidden email])
> 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" <[hidden email]> 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 ([hidden email]) wrote:
>>
>> On 2 March 2018 at 13:31, Oliver Heger
>> <[hidden email]>
>> 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 <[hidden email]>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] new component for timing?

Romain Manni-Bucau
2018-03-15 14:36 GMT+01:00 Otto Fowler <[hidden email]>:

> 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 ([hidden email])
> 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.


>
> > 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 ([hidden email])
> > 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" <[hidden email]> 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 ([hidden email]) wrote:
> >>
> >> On 2 March 2018 at 13:31, Oliver Heger
> >> <[hidden email]>
> >> 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 <[hidden email]>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] new component for timing?

Gilles Sadowski
On Thu, 15 Mar 2018 15:13:39 +0100, Romain Manni-Bucau wrote:

> 2018-03-15 14:36 GMT+01:00 Otto Fowler <[hidden email]>:
>
>> 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 ([hidden email])
>> 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.

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
>> ([hidden email])
>> > 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" <[hidden email]>
>> 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 ([hidden email])
>> wrote:
>> >>
>> >> On 2 March 2018 at 13:31, Oliver Heger
>> >> <[hidden email]>
>> >> 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 <[hidden email]>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] new component for timing?

Romain Manni-Bucau
Le 17 mars 2018 11:49, "Gilles" <[hidden email]> 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 <[hidden email]>:
>
> 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 ([hidden email])
>> 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).



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 ([hidden email])
>> > 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" <[hidden email]> 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 ([hidden email]) wrote:
>> >>
>> >> On 2 March 2018 at 13:31, Oliver Heger
>> >> <[hidden email]>
>> >> 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 <[hidden email]>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] new component for timing?

Gilles Sadowski
On Sat, 17 Mar 2018 12:47:40 +0100, Romain Manni-Bucau wrote:

> Le 17 mars 2018 11:49, "Gilles" <[hidden email]> 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 <[hidden email]>:
>>
>> 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
>>> ([hidden email])
>>> 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
>>> ([hidden email])
>>> > 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" <[hidden email]>
>>> 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 ([hidden email])
>>> wrote:
>>> >>
>>> >> On 2 March 2018 at 13:31, Oliver Heger
>>> >> <[hidden email]>
>>> >> 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 <[hidden email]>
>>>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] new component for timing?

Romain Manni-Bucau
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" <[hidden email]> a écrit :

> On Sat, 17 Mar 2018 12:47:40 +0100, Romain Manni-Bucau wrote:
>
>> Le 17 mars 2018 11:49, "Gilles" <[hidden email]> 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 <[hidden email]>:
>>>
>>> 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 ([hidden email])
>>>> 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 ([hidden email])
>>>> > 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" <[hidden email]> 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 ([hidden email]) wrote:
>>>> >>
>>>> >> On 2 March 2018 at 13:31, Oliver Heger
>>>> >> <[hidden email]>
>>>> >> 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 <[hidden email]>
>>>>
>>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] new component for timing?

Otto Fowler
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 ([hidden email])
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" <[hidden email]> a écrit :

> On Sat, 17 Mar 2018 12:47:40 +0100, Romain Manni-Bucau wrote:
>
>> Le 17 mars 2018 11:49, "Gilles" <[hidden email]> 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 <[hidden email]>:
>>>
>>> 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 ([hidden email])
>>>> 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 ([hidden email])
>>>> > 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" <[hidden email]>
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 ([hidden email]) wrote:
>>>> >>
>>>> >> On 2 March 2018 at 13:31, Oliver Heger
>>>> >> <[hidden email]>
>>>> >> 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 <[hidden email]>
>>>>
>>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] new component for timing?

Bruno P. Kinoshita-3
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 <[hidden email]>
 To: Romain Manni-Bucau <[hidden email]>; Commons Developers List <[hidden email]>
 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 ([hidden email])
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" <[hidden email]> a écrit :

> On Sat, 17 Mar 2018 12:47:40 +0100, Romain Manni-Bucau wrote:
>
>> Le 17 mars 2018 11:49, "Gilles" <[hidden email]> 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 <[hidden email]>:
>>>
>>> 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 ([hidden email])
>>>> 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 ([hidden email])
>>>> > 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" <[hidden email]>
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 ([hidden email]) wrote:
>>>> >>
>>>> >> On 2 March 2018 at 13:31, Oliver Heger
>>>> >> <[hidden email]>
>>>> >> 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 <[hidden email]>
>>>>
>>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

   
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] new component for timing?

Otto Fowler
If monitoring was started a new, and not re-viving the old monitoring?


On March 20, 2018 at 17:56:44, Bruno P. Kinoshita (
[hidden email]) 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 <[hidden email]>
To: Romain Manni-Bucau <[hidden email]>; Commons Developers List <
[hidden email]>
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 ([hidden email])
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" <[hidden email]> a écrit :

> On Sat, 17 Mar 2018 12:47:40 +0100, Romain Manni-Bucau wrote:
>
>> Le 17 mars 2018 11:49, "Gilles" <[hidden email]> 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 <[hidden email]>:
>>>
>>> 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 ([hidden email])
>>>> 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 ([hidden email])
>>>> > 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" <[hidden email]>
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 ([hidden email]) wrote:
>>>> >>
>>>> >> On 2 March 2018 at 13:31, Oliver Heger
>>>> >> <[hidden email]>
>>>> >> 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 <[hidden email]>
>>>>
>>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] new component for timing?

Bruno P. Kinoshita-3
In reply to this post by Otto Fowler
Not sure. I'm not familiar with sirona/commons-monitoring.
Sirona seems to already have a StopWatch, and looks like there's some users already? No strong opinion here, so happy with either of these.


      From: Otto Fowler <[hidden email]>
 To: Romain Manni-Bucau <[hidden email]>; Bruno P. Kinoshita <[hidden email]>; Commons Developers List <[hidden email]>
 Sent: Wednesday, 21 March 2018 11:00 AM
 Subject: Re: [DISCUSS] new component for timing?
 
If monitoring was started a new, and not re-viving the old monitoring?


On March 20, 2018 at 17:56:44, Bruno P. Kinoshita (
[hidden email]) 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 <[hidden email]>
To: Romain Manni-Bucau <[hidden email]>; Commons Developers List <
[hidden email]>
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 ([hidden email])
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" <[hidden email]> a écrit :

> On Sat, 17 Mar 2018 12:47:40 +0100, Romain Manni-Bucau wrote:
>
>> Le 17 mars 2018 11:49, "Gilles" <[hidden email]> 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 <[hidden email]>:
>>>
>>> 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 ([hidden email])
>>>> 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 ([hidden email])
>>>> > 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" <[hidden email]>
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 ([hidden email]) wrote:
>>>> >>
>>>> >> On 2 March 2018 at 13:31, Oliver Heger
>>>> >> <[hidden email]>
>>>> >> 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 <[hidden email]>
>>>>
>>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

   
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] new component for timing?

Gilles Sadowski
In reply to this post by Otto Fowler
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 (
> [hidden email]) 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 <[hidden email]>
> To: Romain Manni-Bucau <[hidden email]>; Commons Developers
> List <
> [hidden email]>
> 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
> ([hidden email])
> 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" <[hidden email]> a
> écrit :
>
>> On Sat, 17 Mar 2018 12:47:40 +0100, Romain Manni-Bucau wrote:
>>
>>> Le 17 mars 2018 11:49, "Gilles" <[hidden email]> 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 <[hidden email]>:
>>>>
>>>> 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
>>>>> ([hidden email])
>>>>> 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
>>>>> ([hidden email])
>>>>> > 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" <[hidden email]>
> 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 ([hidden email])
>>>>> wrote:
>>>>> >>
>>>>> >> On 2 March 2018 at 13:31, Oliver Heger
>>>>> >> <[hidden email]>
>>>>> >> 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 <[hidden email]>
>>>>>
>>>>>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] new component for timing?

Otto Fowler
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 ([hidden email]) 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 (
> [hidden email]) 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 <[hidden email]>
> To: Romain Manni-Bucau <[hidden email]>; Commons Developers
> List <
> [hidden email]>
> 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
> ([hidden email])
> 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" <[hidden email]> a
> écrit :
>
>> On Sat, 17 Mar 2018 12:47:40 +0100, Romain Manni-Bucau wrote:
>>
>>> Le 17 mars 2018 11:49, "Gilles" <[hidden email]> 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 <[hidden email]>:
>>>>
>>>> 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
>>>>> ([hidden email])
>>>>> 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
>>>>> ([hidden email])
>>>>> > 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" <[hidden email]>
> 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 ([hidden email])
>>>>> wrote:
>>>>> >>
>>>>> >> On 2 March 2018 at 13:31, Oliver Heger
>>>>> >> <[hidden email]>
>>>>> >> 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 <[hidden email]>
>>>>>
>>>>>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] new component for timing?

Gilles Sadowski
On Tue, 20 Mar 2018 15:27:45 -0700, Otto Fowler wrote:
> Sirona is gone, it is a closed incubator project.  Romain has forked
> it to
> his own repo.

The code is there; the rationale is the same: some functionality
started "here" and got "there".
Is anyone interested to get (part of) it back "here"?

Gilles

> On March 20, 2018 at 18:24:06, Gilles ([hidden email])
> 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 (
>> [hidden email]) 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 <[hidden email]>
>> To: Romain Manni-Bucau <[hidden email]>; Commons Developers
>> List <
>> [hidden email]>
>> 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
>> ([hidden email])
>> 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" <[hidden email]> a
>> écrit :
>>
>>> On Sat, 17 Mar 2018 12:47:40 +0100, Romain Manni-Bucau wrote:
>>>
>>>> Le 17 mars 2018 11:49, "Gilles" <[hidden email]> 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 <[hidden email]>:
>>>>>
>>>>> 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
>>>>>> ([hidden email])
>>>>>> 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
>>>>>> ([hidden email])
>>>>>> > 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" <[hidden email]>
>> 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 ([hidden email])
>>>>>> wrote:
>>>>>> >>
>>>>>> >> On 2 March 2018 at 13:31, Oliver Heger
>>>>>> >> <[hidden email]>
>>>>>> >> 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 <[hidden email]>
>>>>>>
>>>>>>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] new component for timing?

Romain Manni-Bucau
In reply to this post by Otto Fowler
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" <[hidden email]> 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 ([hidden email])
> 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 (
> > [hidden email]) 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 <[hidden email]>
> > To: Romain Manni-Bucau <[hidden email]>; Commons Developers
> > List <
> > [hidden email]>
> > 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
> > ([hidden email])
> > 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" <[hidden email]> a
> > écrit :
> >
> >> On Sat, 17 Mar 2018 12:47:40 +0100, Romain Manni-Bucau wrote:
> >>
> >>> Le 17 mars 2018 11:49, "Gilles" <[hidden email]> 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 <[hidden email]>:
> >>>>
> >>>> 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
> >>>>> ([hidden email])
> >>>>> 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
> >>>>> ([hidden email])
> >>>>> > 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" <[hidden email]>
> > 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 ([hidden email])
> >>>>> wrote:
> >>>>> >>
> >>>>> >> On 2 March 2018 at 13:31, Oliver Heger
> >>>>> >> <[hidden email]>
> >>>>> >> 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 <[hidden email]>
> >>>>>
> >>>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] new component for timing?

Otto Fowler
How about commons-timing, having StopWatch, StackWatch and other classes
that
we can find?



On March 20, 2018 at 18:40:05, Romain Manni-Bucau ([hidden email])
wrote:

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" <[hidden email]> 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 ([hidden email])
> 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 (
> > [hidden email]) 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 <[hidden email]>
> > To: Romain Manni-Bucau <[hidden email]>; Commons Developers
> > List <
> > [hidden email]>
> > 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
> > ([hidden email])
> > 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" <[hidden email]> a
> > écrit :
> >
> >> On Sat, 17 Mar 2018 12:47:40 +0100, Romain Manni-Bucau wrote:
> >>
> >>> Le 17 mars 2018 11:49, "Gilles" <[hidden email]> 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 <[hidden email]>:
> >>>>
> >>>> 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
> >>>>> ([hidden email])
> >>>>> 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
> >>>>> ([hidden email])
> >>>>> > 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" <[hidden email]>
> > 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 ([hidden email])
> >>>>> wrote:
> >>>>> >>
> >>>>> >> On 2 March 2018 at 13:31, Oliver Heger
> >>>>> >> <[hidden email]>
> >>>>> >> 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 <[hidden email]>
> >>>>>
> >>>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] new component for timing?

garydgregory
On Wed, Mar 28, 2018 at 11:14 AM, Otto Fowler <[hidden email]>
wrote:

> How about commons-timing, having StopWatch, StackWatch and other classes
> that
> we can find?
>

I think we start small with only what we need and have today, namely these
two classes.

Gary


>
>
>
> On March 20, 2018 at 18:40:05, Romain Manni-Bucau ([hidden email])
> wrote:
>
> 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" <[hidden email]> 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 ([hidden email])
> > 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 (
> > > [hidden email]) 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 <[hidden email]>
> > > To: Romain Manni-Bucau <[hidden email]>; Commons Developers
> > > List <
> > > [hidden email]>
> > > 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
> > > ([hidden email])
> > > 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" <[hidden email]> a
> > > écrit :
> > >
> > >> On Sat, 17 Mar 2018 12:47:40 +0100, Romain Manni-Bucau wrote:
> > >>
> > >>> Le 17 mars 2018 11:49, "Gilles" <[hidden email]> 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 <[hidden email]>:
> > >>>>
> > >>>> 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
> > >>>>> ([hidden email])
> > >>>>> 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
> > >>>>> ([hidden email])
> > >>>>> > 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" <[hidden email]>
> > > 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 ([hidden email])
> > >>>>> wrote:
> > >>>>> >>
> > >>>>> >> On 2 March 2018 at 13:31, Oliver Heger
> > >>>>> >> <[hidden email]>
> > >>>>> >> 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 <[hidden email]>
> > >>>>>
> > >>>>>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] new component for timing?

Otto Fowler
OK, sounds fine to me.  Hopefully we’ll get some buy in and can move
forward.
I’m not sure what is next though ;)



On March 28, 2018 at 13:17:22, Gary Gregory ([hidden email]) wrote:

On Wed, Mar 28, 2018 at 11:14 AM, Otto Fowler <[hidden email]>
wrote:

> How about commons-timing, having StopWatch, StackWatch and other classes
> that
> we can find?
>

I think we start small with only what we need and have today, namely these
two classes.

Gary


>
>
>
> On March 20, 2018 at 18:40:05, Romain Manni-Bucau ([hidden email])
> wrote:
>
> 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" <[hidden email]> 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 ([hidden email])
> > 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 (
> > > [hidden email]) 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 <[hidden email]>
> > > To: Romain Manni-Bucau <[hidden email]>; Commons Developers
> > > List <
> > > [hidden email]>
> > > 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
> > > ([hidden email])
> > > 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" <[hidden email]> a
> > > écrit :
> > >
> > >> On Sat, 17 Mar 2018 12:47:40 +0100, Romain Manni-Bucau wrote:
> > >>
> > >>> Le 17 mars 2018 11:49, "Gilles" <[hidden email]> 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 <[hidden email]>:
> > >>>>
> > >>>> 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
> > >>>>> ([hidden email])
> > >>>>> 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
> > >>>>> ([hidden email])
> > >>>>> > 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" <[hidden email]>
> > > 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 ([hidden email])
> > >>>>> wrote:
> > >>>>> >>
> > >>>>> >> On 2 March 2018 at 13:31, Oliver Heger
> > >>>>> >> <[hidden email]>
> > >>>>> >> 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 <[hidden email]>
> > >>>>>
> > >>>>>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
123