Re: [cdt-dev] EDC and asynchronous operations

["Burton, Felix" <Felix.Burton@xxxxxxxxxxxxx>]

> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
> On Behalf Of John Cortell
> Sent: Tuesday, October 12, 2010 12:21 PM
> To: CDT General developers list.; cdt-dev@xxxxxxxxxxx
> Subject: Re: [cdt-dev] EDC and asynchronous operations
> 
> At 12:34 PM 10/12/2010, Tarassov, Eugene wrote:
> >Hi John,
> >
> > > Interesting idea...using ACPM for client access. But I'm not sure
how
> >practical that would be. Clients using such access would be
unreliable,
> >right? If the cache is invalidated, the client is screwed unless it
has
> >a plan B to use the asynchronous calls. And coding something to try
one
> >way (simple), then another if needed (harder) isn't really a
> >simplification. Then again, perhaps I'm misunderstanding your
> >suggestion. Or perhaps you're thinking of situations where the client
is
> >willing to abort the request altogether if the cache is invalid (even
> >though real-time data could be obtained)
> >
> >If a client encounter an invalid cache item, it can choose:
> >  1. Abort the transaction and return an error.
> >  Or 2. Start data retrieval on the item, add the transaction to the
wait
> >list of the item, re-run the transaction when item state changes.
> >Most clients choose #2.
> 
> Right. All I'm saying is that exposing a cache item to a DSF client
> in an attempt to simplify things for the client is a questionable
> direction, given what I know of ACPM. If you look at the example
> Pawel suggested, the benefit of exposing such an API would be that
> the client can make a synchronous call instead of an
> asynchronous...but it's not really that simple. The client has to
> deal with the fact that the cache may be invalid. That will require
> an asynchronous operation, the avoidance of which was the point of
> adding the cache-based variant. Now, that's not to say ACPM doesn't
> have advantages. I think it could be quite useful for a client that
> needs to get a set of data points, each of which would normally
> require an async operation. But as far as DSF exposing sync variants
> of its services that return cache objects, the benefit is dubious to
> me. Maybe there's something I'm missing.
> 
> >
> > > But, again, it seems useful only when you know up front exactly
what
> >set of data points you need for the transaction.
> >
> >Not sure what you mean. A transaction code decides at run time what
data
> >points to accesses. In fact, this is one of biggest benefits of ACPM:
> >you can write transaction code as traditional sequential code, using
> >'if' and 'for' statements, recursive calls, etc., and access all
cached
> >data as normal variables, without programming call-backs for every
data
> >access. But to be able to do that, you need to wrap into cache items
all
> >your remote data and everything derived from remote data, and various
> >getSomething functions need to return cache item instead of actual
data.
> 
> I understand that. But if you don't know what exactly you will need
> up front, then ACPM is of little use, IMO. E.g., I may know that I
> need A and B, but until I have B I don't know if I'll need C and D.
> And depending on D, I may need E, or F but not both. And if F is some
> particular value, then I need G, H, I, J and K. Such a use case could
> probably not be properly and/or efficiently implemented using ACPM, I
> believe.
> 
> 
> 
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev