Hi Jean-Sebastian,
> - In several places you mention 'a SCA portable data store component' > or 'this component' for example. I suggest to do a pass over the text > of the proposal and make really clear that there are multiple > components, one (or two... see my next question) per data store type, > to avoid any confusion. > > - Are you planning to have just one component per data store type? or > two components per data store type? maybe one component wrapping and > providing as a service the technical database API for the specific > datastore, and a second component providing that uniform REST data > access on top? I was not sure of your intention after reading the > description of your component reference... If I had to pick a design > I'd probably choose two separate components, but I leave that decision > to you, and perhaps this is something that you don't even need to > decide now... but only after you actually investigate the various > APIs. What do you think? > I have the same idea as you mentioned, having two separate components. One for wrapping and the other one for provide uniform REST data access on the top. This will help us to make a composite component which has all the components. Also if we need to change the model we can change that accordingly. I'll make the confusion correct in the project proposal. > - I'm not sure if having interaction policies to handle database > authentication is going to be too much additional work for this > project. You already have to deal with the integration of three > databases, which is going to be a lot of work by itself. What do > others in the team think? > Yes I agreed there are lots of work to be done if we provide this functionality since we have to use (or create) components which give the identity services. Since we don't have much time, I think we should postponed it to after summer of code. - I'd suggest to include a few things in the Apr 25 - May 23 phase: > a) define a common tutorial / sample scenario that you're going to > implement over the various databases in the next phases > b) start to hack small parts of the scenario over the databases, > without Tuscany in the picture, as an exercise to learn their APIs > c) start to put together the database independent parts of the > scenario in Tuscany, and mock up the database access for this > > That's a good idea. Thanks for the suggestions and I will modify the proposal according to them. > I'm hoping that doing that up front will help provide some context > while you're experimenting with the database APIs and prepare you > better to shape up the common service interface you're planning to > design in phase 2. What do you think? > > I somewhat families with the API of the Apache Cassandra and I am currently looking at the other APIs and I will come up with a primary level interface soon. Thanks Eranda
