Re: SDO C++ compliance with 2.1 spec - help needed
Caroline Maynard wrote: However we don't have a huge amount of code, and it is very simple to download it from cvs using pserver:[EMAIL PROTECTED]:/repository checkout pecl/sdo and load it into cscope or similar, so you could easily check for references that way. Or you could just mail us :-) I like the gmane address obfuscation, but there are times when it goes too far. Try pserver:[EMAIL PROTECTED]:/repository checkout pecl/sdo for that cvs repository - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SDO C++ compliance with 2.1 spec - help needed
Pete Robbins wrote: On 25/06/07, Caroline Maynard [EMAIL PROTECTED] wrote: A fair amount actually, but I am making an assumption that once the changes are in place, the migration effort will be largely refactoring. That is, that the non-spec function will resurface in Tuscany implementation classes (if not adopted by the spec). If this is not the case, then the response from the php implementation could be different. Do you have a list of the non-spec interfaces PHP is using? I believe the getUserData interfaces were added for PHP use?? Yes, the UserData stuff was added as somewhere for consumers (like PHP) to be able to augment the DataObject with their own data, and it's crucial to our implementation. I've given some thought as to how we could easily create a definitive list of the Tuscany APIs employed. But since the PHP implementation includes the Tuscany code, we don't have the ability to simply list the external references as we would for a dynamic library, unless you can suggest another way. However we don't have a huge amount of code, and it is very simple to download it from cvs using pserver:[EMAIL PROTECTED]:/repository checkout pecl/sdo and load it into cscope or similar, so you could easily check for references that way. Or you could just mail us :-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SDO C++ compliance with 2.1 spec - help needed
On 25/06/07, Caroline Maynard [EMAIL PROTECTED] wrote: Simon Laws wrote: On 6/23/07, Pete Robbins [EMAIL PROTECTED] wrote: I have created a maintenance branch */incubator/tuscany/branches/sdo- cpp-pre2.1/* Work towards SDO 2.1 specification compliance will continue in HEAD. Pete, thanks for creating the branch, it will be helpful in keeping the php implementation stable while this is going on. I understand it's hard to say how long you think the branch will be necessary, but are you going to have some groundrules about the use of the branch? I would hate to see the branch and the trunk diverging, in the sense of fixes being applied to one and not the other. I would anticipate only putting fixes into the branch on request. Any fix in the branch should also be applied to HEAD. Sorry Pete, was a bit slow off the mark getting to your email. The branch approach works fine for PHP SCA_SDO. We should be doing ongoing development for C++ SDO in HEAD so no problems from my point of view. I don't know how much of the non specified interface to C++ SDO the PHP SDO implementatoin is using if any but we should be trying to work toward the specified interface also. A fair amount actually, but I am making an assumption that once the changes are in place, the migration effort will be largely refactoring. That is, that the non-spec function will resurface in Tuscany implementation classes (if not adopted by the spec). If this is not the case, then the response from the php implementation could be different. Do you have a list of the non-spec interfaces PHP is using? I believe the getUserData interfaces were added for PHP use?? Cheers, - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Pete
Re: SDO C++ compliance with 2.1 spec - help needed
Simon Laws wrote: On 6/23/07, Pete Robbins [EMAIL PROTECTED] wrote: I have created a maintenance branch */incubator/tuscany/branches/sdo- cpp-pre2.1/* Work towards SDO 2.1 specification compliance will continue in HEAD. Pete, thanks for creating the branch, it will be helpful in keeping the php implementation stable while this is going on. I understand it's hard to say how long you think the branch will be necessary, but are you going to have some groundrules about the use of the branch? I would hate to see the branch and the trunk diverging, in the sense of fixes being applied to one and not the other. Sorry Pete, was a bit slow off the mark getting to your email. The branch approach works fine for PHP SCA_SDO. We should be doing ongoing development for C++ SDO in HEAD so no problems from my point of view. I don't know how much of the non specified interface to C++ SDO the PHP SDO implementatoin is using if any but we should be trying to work toward the specified interface also. A fair amount actually, but I am making an assumption that once the changes are in place, the migration effort will be largely refactoring. That is, that the non-spec function will resurface in Tuscany implementation classes (if not adopted by the spec). If this is not the case, then the response from the php implementation could be different. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SDO C++ compliance with 2.1 spec - help needed
On 6/23/07, Pete Robbins [EMAIL PROTECTED] wrote: I have created a maintenance branch */incubator/tuscany/branches/sdo- cpp-pre2.1/* Work towards SDO 2.1 specification compliance will continue in HEAD. Cheers, On 22/06/07, Pete Robbins [EMAIL PROTECTED] wrote: As is shown by the analysis that Michael Yoder is doing, comparing SDO 2.1spec API vs Tuscany SDO C++ API, it is clear that there will be a fair amount of work involved in getting the Tuscany code in to shape. Some changes are fairly simple but others may need wide ranging changes in the way Tuscany SDO is implemented. This will not be done overnight. I'd like to propose that we cut a branch of the current code and start the 2.1 work in HEAD (or should the 2.1 work start in a branch?). I know the PHP SCA community are using a cut later than M3 with some fixes I have written and expect them to raise more problems from time to time, this is why I'd like a maintenance branch available while we work on a 2.1compliany implementation. Would anyone else (committer or not) like to help out with the 2.1effort? Cheers, -- Pete -- Pete Sorry Pete, was a bit slow off the mark getting to your email. The branch approach works fine for PHP SCA_SDO. We should be doing ongoing development for C++ SDO in HEAD so no problems from my point of view. I don't know how much of the non specified interface to C++ SDO the PHP SDO implementatoin is using if any but we should be trying to work toward the specified interface also. Simon
SDO C++ compliance with 2.1 spec - help needed
As is shown by the analysis that Michael Yoder is doing, comparing SDO 2.1spec API vs Tuscany SDO C++ API, it is clear that there will be a fair amount of work involved in getting the Tuscany code in to shape. Some changes are fairly simple but others may need wide ranging changes in the way Tuscany SDO is implemented. This will not be done overnight. I'd like to propose that we cut a branch of the current code and start the 2.1 work in HEAD (or should the 2.1 work start in a branch?). I know the PHP SCA community are using a cut later than M3 with some fixes I have written and expect them to raise more problems from time to time, this is why I'd like a maintenance branch available while we work on a 2.1 compliany implementation. Would anyone else (committer or not) like to help out with the 2.1 effort? Cheers, -- Pete
