[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [cdt-dev] [DSF] SessionType
- From: Marc Khouzam <marc.khouzam@xxxxxxxxxxxx>
- Date: Fri, 9 Jul 2010 08:50:45 -0400
- Accept-language: en-US
- Acceptlanguage: en-US
- Delivered-to: firstname.lastname@example.org
- Thread-index: AcsfCeJOxuRWRoA4RDWTKAuM7zbASAAW2UCQ
- Thread-topic: [cdt-dev] [DSF] SessionType
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of John Cortell
Sent: Thursday, July 08, 2010 9:54 PM
To: CDT General developers list.; CDT General developers list.
Subject: Re: [cdt-dev] [DSF] SessionType
At 08:41 PM 7/8/2010, Doug Schaefer wrote:
On Thu, Jul 8, 2010 at 1:46 PM, Marc Khouzam <marc.khouzam@xxxxxxxxxxxx> wrote:
>> -----Original Message-----
>> From: Vladimir Prus [ mailto:vladimir@xxxxxxxxxxxxxxxx <mailto:vladimir@xxxxxxxxxxxxxxxx> ]
>> Sent: Thursday, July 08, 2010 12:39 PM
>> To: cdt-dev@xxxxxxxxxxx
>> Cc: Marc Khouzam
>> Subject: Re: [cdt-dev] [DSF] SessionType
>> I am becoming somewhat concerned :-( You seem to suggest that
>> overridding a service -- that is, writing my own service class
>> and doing what I want -- is a sensible approach.
> Yes. That's DSF.
And I'll never forget the day we learned about DSF and were told that.
I was floored. It is not a sensible approach and one of the main
reasons I still don't like DSF (the complex asynchronous programming
model being the other one). If you want DSF to have a higher adoption
rate, this needs to be addressed.
Why is that so alarming? DSF is more about a framework and a standardized set of service interfaces than it is about specific implementations of those interfaces. If the stock implementations don't meet your needs then, worst case, you provide your own. This doesn't mean that the base implementations can't be made flexible to accommodate different environment and use cases, but at the end of the day, they're not going to meet everyone's needs.