So are you thinking about a specific services interface for an SDO object, i.e. the SDO acts as a conduit between the data resource and the client (browser)? In this scenario what happens when data is changed. Does the SDO cache the change awaiting the request to update the data resource or does it pass the update directly through to the data resource. There are a number of examples of web services type implementations of access to relational and file data. Would you propose that we adopt and exisitng interface description or construct a service interface that wraps the SDO interface as currently specified?
Regards Simon On 5/4/06, Edward Slattery <[EMAIL PROTECTED]> wrote:
With regard to the interop scenario concerning moving data graphs from location to location, I am a bit concerned that we are not covering the other option. With the coming of AJAX, some people are looking more at leaving the data where it is, and using the API to modify it on the server. How does this fit with SDO? Currently (certainly in the C++ implementation), we load the data into objects in memory from the data storage, and can then serialize them to XML to be moved around. If we imagine a case where ajax is used to call get/set APIs on data objects, then perhaps we dont even need to load the data from the database until its used. I feel the need for an SDO implmentation which just wraps data access, and does nothing until a data object is actually requested, at which point it uses whatever mechanism is used by the data access service (stored procs etc) to load that individual data object, and send that to the client. Perhaps thats really a separate thread - what do you all think? On 03/05/06, Kevin Williams <[EMAIL PROTECTED]> wrote: > > kelvin goodson wrote: > [snip] > > > > > With regards to sharing change histories, I imagine the primary use > case > > for change histories is when you give a give a modified graph back to > the > > "same" DAS for writing back to the original source. So I in terms of > > cross > > language interoperability I would extrapolate that the scenario we > > would be > > supporting would be that of fairly tightly coupled DAS > > implementations, all > > accessing the same source. I may be wrong, but It doesn't sound like a > > frequently encountered scenario, so whilst it sounds like goodness, it > > wouldn't be at the top of my priority list. > > > [snip] > > I have also not seen many interop scenarios requiring cooperation > between two different DAS implementations. The only one that comes to > mind is reading from one database and writing to another. This would be > very cool, especially if the two DAS implementations were in different > languages(C++, Java, PHP, Ruby), but I doubt that this scenario will be > common. > > I think a more frequent interop scenario will involve reading data from > a data source and shipping it to some remote engine for processing. The > modified graph would be shipped back to the originating DAS and the > changes reflected to the originating data source. The remote engine > could be implemented in another language or, if it is the same language, > it could be using a different implementation of SDO. > >
