RE: [smila-dev] RE: FYI :: new feature :: Message Resequencer

[Thomas Menzel <tmenzel@xxxxxxx>]

Hi igor,

i forgot to ask you if you can agree to this process:

> Well, I thought I exactly did that. Namely in sections "core problem"
> and "indexing requirements", or not?
> past mails have also been a discussion how and if certain conditions
> exist that violate requirements.
> 
> So, if you think any of the requirements listed and explained so far,
> doesn't exist or is wrong, then say so.
> But if it does, then we need to find a solution to meet it.
> Agreed, not all will be equally important and in some scenarios the
> requirement is already met as the condition doesn't arise in the
> application, eg. we just have a project where we use agents and they
> said that they wont have changes in close succession. Fine, that is
> great. but only in that project. There might be another where that is
> not the case.
> 
> As I wrote in my last mail: my setout is to look for a solution that
> meets _all_ requirements _independent_ of their likely hood to happen.
> 
> A 2nd step then is to see if the effort to implementation the solution
> (or maybe there is not just one but several to combine) is worth the
> requirement it meets and here, and *only* here, is the point where the
> likelihood of the occurrence comes into the decision process.

I forgot to add also add that selecting a solution will also have to consider it particular drawbacks and performance costs etc.

Kind regards
Thomas Menzel @ brox IT-Solutions GmbH


> -----Original Message-----
> From: smila-dev-bounces@xxxxxxxxxxx [mailto:smila-dev-
> bounces@xxxxxxxxxxx] On Behalf Of Thomas Menzel
> Sent: Dienstag, 6. Oktober 2009 22:59
> To: Smila project developer mailing list
> Subject: RE: [smila-dev] RE: FYI :: new feature :: Message Resequencer
> 
> Hi,
> 
> > I have the impression, that you've missed my point:
> > You are constantly debating the approach to solve the problem,
> 
> I'm suggesting a solution that meets (all) the requirements. And IMOH
> I'm arguing how it does that and how others do or don't.
> 
> > while I
> > want to define the problem and the solution requirements first.
> 
> Well, I thought I exactly did that. Namely in sections "core problem"
> and "indexing requirements", or not?
> past mails have also been a discussion how and if certain conditions
> exist that violate requirements.
> 
> So, if you think any of the requirements listed and explained so far,
> doesn't exist or is wrong, then say so.
> But if it does, then we need to find a solution to meet it.
> 
> Agreed, not all will be equally important and in some scenarios the
> requirement is already met as the condition doesn't arise in the
> application, eg. we just have a project where we use agents and they
> said that they wont have changes in close succession. Fine, that is
> great. but only in that project. There might be another where that is
> not the case.
> 
> As I wrote in my last mail: my setout is to look for a solution that
> meets _all_ requirements _independent_ of their likely hood to happen.
> 
> A 2nd step then is to see if the effort to implementation the solution
> (or maybe there is not just one but several to combine) is worth the
> requirement it meets and here, and *only* here, is the point where the
> likelihood of the occurrence comes into the decision process.
> 
> 
> > My major points are:
> >  1. This problem does currently exist.
> +1
> 
> >  2. The occurrence is quite low - in real word use cases.
> +1
> ... which is also the reason we didn't cover it yet
> 
> >  3. In order to be highly scalable _we must take care_ that this
> > problem
> > does not occur
> 
> +/-1
> 
> +1 for the last part of the sentence, but it is not a consequence of
> wanting to be scalable, or what do you mean by this?
> solving this matter (execution of operations in proper order or their
> consolidation) doesn't bring us any perf. gain per say. More likely is,
> that we lose performance by solving the issue.
> 
> If I may rephrase this point, as I would see it:
> 
> 	In order to provide a correctly working solution in all
> circumstances
> 	> _we must take care_ that this
> 	> problem
> 	> does not occur
> 
> 
> > Therefore I would define the _real_ problem as: "How to make sure
> that
> > the execution order of operations on _one_ particular record _does
> not_
> > matter."
> > Can we agree on this?
> 
> If that is possible, to transform the problem into that: great! Let's
> hear it.
> 
> 
> So long and good night.
> 
> Kind regards
> Thomas Menzel @ brox IT-Solutions GmbH
> 
> > -----Original Message-----
> > From: smila-dev-bounces@xxxxxxxxxxx [mailto:smila-dev-
> > bounces@xxxxxxxxxxx] On Behalf Of Igor.Novakovic@xxxxxxxxxxx
> > Sent: Dienstag, 6. Oktober 2009 17:04
> > To: smila-dev@xxxxxxxxxxx
> > Subject: AW: [smila-dev] RE: FYI :: new feature :: Message
> Resequencer
> >
> > Hi Thomas,
> >
> > > Before I answer all your questions (and I feel rather silly about
> > that) I think
> > > the main diff. between our two approaches are, that you are looking
> > for a solution
> > > that works 90% of the times while I have been thinking about a
> > solution that works
> > > 100% of the times (at least I hope so) and hence the elaborate wiki
> > page.
> > I have the impression, that you've missed my point:
> > You are constantly debating the approach to solve the problem, while
> I
> > want to define the problem and the solution requirements first.
> >
> > So to avoid further misunderstanding I'll try to be very brief:
> >
> > The problem (that you're trying to solve with resequencer) can be
> > defined as: "The execution order of operations on _one_ particular
> > record _does_ matter and _must be_ obeyed."
> >
> > My major points are:
> >  1. This problem does currently exist.
> >  2. The occurrence is quite low - in real word use cases.
> >  3. In order to be highly scalable _we must take care_ that this
> > problem
> > does not occur!
> > Therefore I would define the _real_ problem as: "How to make sure
> that
> > the execution order of operations on _one_ particular record _does
> not_
> > matter."
> > Can we agree on this?
> >
> > BTW: I would be very happy if other team members would join this IMO
> > important discussion. Guys, please participate!
> >
> > Regards
> > Igor
> > _______________________________________________
> > smila-dev mailing list
> > smila-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/smila-dev
> >
> > No virus found in this incoming message.
> > Checked by AVG - www.avg.com
> > Version: 8.5.420 / Virus Database: 270.14.4/2417 - Release Date:
> > 10/06/09 06:50:00
> _______________________________________________
> smila-dev mailing list
> smila-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/smila-dev
> 
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.5.420 / Virus Database: 270.14.4/2417 - Release Date:
> 10/06/09 06:50:00