[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [cdt-dev] [DSF] SessionType
|
> -----Original Message-----
> From: Vladimir Prus [mailto:vladimir@xxxxxxxxxxxxxxxx]
> Sent: Thursday, July 08, 2010 12:54 PM
> To: cdt-dev@xxxxxxxxxxx
> Cc: Marc Khouzam
> Subject: Re: [cdt-dev] [DSF] SessionType
>
> On Thursday 08 July 2010 20:50:42 Marc Khouzam wrote:
>
> >
> > > -----Original Message-----
> > > From: cdt-dev-bounces@xxxxxxxxxxx
> > > [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of John Cortell
> > > Sent: Thursday, July 08, 2010 12:42 PM
> > > To: CDT General developers list.; CDT General developers list.
> > > Subject: Re: [cdt-dev] [DSF] SessionType
> > >
> > > One thing I've observed is that there seems to be a
> hesitancy to bump
> > > the major version of DSF and DSF-GDB. With a noticeable
> increase in
> > > adopters, I suspect a lot of holes and bad assumptions
> are going to
> > > surface. Attempting to tackle these issues without
> breaking backward
> > > compatibility is going to yield some pretty ugly results, IMO. I
> > > think we should be willing to accept a major version
> change in Indigo
> > > and start opening the table to well architected solutions
> to these
> > > problems rather than convoluted ones which maintain backwards
> > > compatibilities but hurt DSF in the long run.
> >
> > That is a good point.
> > But let's not up the version for a specific solution for one
> > particular case. But if we have a "well architected solution"
> > that will help many integrators, it does seem like it is worth
> > the change in version.
>
> How can integrators determine that a "well architectured solution"
> is indeed such, and solves their problem? It's only possible if it's
> used in a real product, which suggests you need some branch where
> it is kept until maturity.
I was thinking of such solutions as a "Services factory" and
"Command factory" which we have added to DSF-GDB. Those seem like
a good general improvement.
A new method in an existing interface for one specific scenario
does not seem like a good enough reason to up the version.
There are other ways instead, like creating a new interface.
Marc
>
> Thanks,
>
> --
> Vladimir Prus
> CodeSourcery
> vladimir@xxxxxxxxxxxxxxxx
> (650) 331-3385 x722
>
