On 7/13/06, cr22rc <[EMAIL PROTECTED]> wrote:
Here are some comments for the SDO windows cpp binary package: Why does the "binary" GettingStarted.html talk about "Building and"... binary should be built already.
Unlike getting the Axis2c requirement that seemed pretty straight
forward, the libxml2 pages to find the right version seemed a bit more painful. I finally ended up here: http://www.zlatkovic.com/pub/libxml/oldreleases/libxml2-2.6.20.win32.zip And still am not 100% sure if I have the right libxml2. Was there a particular reason this link can't also be added to the GettingStarted.html so I could just click on it? (I know this link could go bad in the future, but I'd gamble it would stay current long enough for M1 and make it easy for users to get.)
The three separate files GettingStarted.html readme and INSTALL adds for
me a whole lot of confusion. GettStarted.html tells you look at README and it almost immediately tells you go back to GettingStarted.html . If these files all need to be there take two simplify them and make them just pointers to the other. I don't see why most of the README couldn't be rolled up into a section in GettingStarted.html. Same for INSTALL... in fact INSTALL could be made a whole lot nicer cause you could either put the separate platforms in different html files linked or in separate sections that had anchors you could point to.
We use the same README, INSTALL and GettingStarted.html for all platforms and all distros which makes managing our documentation easy.. README and INSTALL are standard C++ project documentation files which veteran C++ developers will go to directly. Rolling this information into GettingStarted.html as well would cause maintenance headaches, so, for less experienced C++ developers we included the GettingStarted.html and linked to these text files. I don't think there is any issue with cross linking between these docs - README is a standard README, INSTALL tells you how to install and GettingStarted provides a nice documentation front page for newbies. Now that I have the SDO binary installed what next ? Samples? Yep - go for it. You have committer access? Make us some. Pete Robbins wrote:
> I have posted a 2nd candidate for the first C++ release here: > http://people.apache.org/~robbinspg/RC-2<http://people.apache.org/%7Erobbinspg/RC-2> > > > Please vote to publish the Milestone 1 release distributions. Please > take some time to download the distributions, review them and test them > in your environment before voting. > > The vote is open for at least the next 72 hours. > At least three +1 votes are required, and only the votes from > Tuscany committers are binding. If the majority of all votes is > positive, I will send a summary of that vote to the Incubator's general > list to formally request the Incubator PMC to approve the Tuscany C++ > Milestone 1 release. For your reference the Incubator release policy > guidelines are available at > http://incubator.apache.org/incubation/Incubation_Policy.html#Releases. > > > > Release Summary > ============= > > Tuscany SCA C++ provides a runtime implementation for the Service > Component > Architecture 0.9 specification, written in C++ and will currently support > C++ > component implementation types. This is not yet a complete implementation > and > known restrictions are described below. > > Supported SCA Assembly Model features > * All features are supported unless listed under the known restrictions > below. See SCA Assembly Model specification. > > Supported language bindings > * Component implementations written in C++. See SCA Client and > Implementation Model specification. > * Component interfaces described by C++ classes. See SCA Client and > Implementation Model specification. > > Supported external service and entry point bindings > * The web service binding is supported. This implementation will support > web services which using document literal SOAP bindings conforming to > the > WS-I basic profile (rpc/encoded is not yet supported). > > Known restrictions > * Subsystem: wiring, entry points and external services are not > supported. > * Local service interfaces cannot use overloaded operations (the SCA > specification limits remote service interfaces to not using > overloaded operations). > * Each WSDL definition for a web service binding must be in a single > WSDL > document. > * No load time validation of the deployed SCA application (run time > validation only). > * No metadata API. > > A sample is included which demonstrates deploying an SCA module, > component > wiring, locating and invoking C++ service from C++ component, > invoking from > a C++ client, and exposing a service as a web service using ws binding. > > > Cheers, > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
