Dear the Boost developers, I'd like to participate in GSoC 2010 event. Could you please review my idea. I very much appreciate your opinion about this. We have ability to generate OOP wrappers by the XSD schema in the popular languages( such as Java or C#) but have not in the C++. With such a tool we will be able to generate C++ classes or structures with functionality of serialization/deserialization from/to XML. Implementation of SOAP webservice client will be easy task( or writing webservice itself). We can create tool (for example xsd2cpp) under boost.xml library and include it to the boost.build. Thanks, Viktar Sialiuk
I created that exact transformation in XSLT, going from XSD to marshallable C++ classes. Would you use Boost for this new transformation? I assume you did not use Boost (nor C++) for the existing transformations (to Java and C#), is that correct? /David On Mar 22, 2010, at 11:43 AM, Viktar Sialiuk wrote:
Dear the Boost developers,
I'd like to participate in GSoC 2010 event. Could you please review my idea. I very much appreciate your opinion about this.
We have ability to generate OOP wrappers by the XSD schema in the popular languages( such as Java or C#) but have not in the C++. With such a tool we will be able to generate C++ classes or structures with functionality of serialization/deserialization from/to XML. Implementation of SOAP webservice client will be easy task( or writing webservice itself). We can create tool (for example xsd2cpp) under boost.xml library and include it to the boost.build.
Thanks, Viktar Sialiuk _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
There are two potential Boost aspects: 1. The transformation tool could use and extend on Boost 2. The generated C++ classes could depend on Boost, and possibly be associated with a thin tailored XML library Could you describe a bit more? /David On Mar 22, 2010, at 1:25 PM, David Bergman wrote:
I created that exact transformation in XSLT, going from XSD to marshallable C++ classes.
Would you use Boost for this new transformation? I assume you did not use Boost (nor C++) for the existing transformations (to Java and C#), is that correct?
/David
On Mar 22, 2010, at 11:43 AM, Viktar Sialiuk wrote:
Dear the Boost developers,
I'd like to participate in GSoC 2010 event. Could you please review my idea. I very much appreciate your opinion about this.
We have ability to generate OOP wrappers by the XSD schema in the popular languages( such as Java or C#) but have not in the C++. With such a tool we will be able to generate C++ classes or structures with functionality of serialization/deserialization from/to XML. Implementation of SOAP webservice client will be easy task( or writing webservice itself). We can create tool (for example xsd2cpp) under boost.xml library and include it to the boost.build.
Thanks, Viktar Sialiuk _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Hi David, 1. The transformation tool will generate CPP wrappers that will use boost.serialization for marshalling. Yes, we can use XSLT for the transformation, but we should be able to process for example XSD imports. So XSLT can be used as part of implementation. 2. Second idea. What do you think about creating XSLT processor under boost.xml library?
Viktar Sialiuk wrote:
We have ability to generate OOP wrappers by the XSD schema in the popular languages( such as Java or C#) but have not in the C++. With such a tool we will be able to generate C++ classes or structures with functionality of serialization/deserialization from/to XML. Implementation of SOAP webservice client will be easy task( or writing webservice itself). We can create tool (for example xsd2cpp) under boost.xml library and include it to the boost.build.
Are you aware of XSD (<http://www.codesynthesis.com/products/xsd/>)? _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
Hi Robert, No, I didn't know about CodeSyntesis XSD. I'll try to read more about this library. Thanks, Viktar Sialiuk
Stewart, Robert wrote:
Viktar Sialiuk wrote:
We have ability to generate OOP wrappers by the XSD schema in the popular languages( such as Java or C#) but have not in the C++. With such a tool we will be able to generate C++ classes or structures with functionality of serialization/deserialization from/to XML. Implementation of SOAP webservice client will be easy task( or writing webservice itself). We can create tool (for example xsd2cpp) under boost.xml library and include it to the boost.build.
Are you aware of XSD (<http://www.codesynthesis.com/products/xsd/>)?
Along these lines, it always seemed to me that someone might want to make a variation of xml_oarchive which wrote out an xml schema rather than the xml data. I don't know so much about xml so as to know it would be useful, but I don't think it would be very hard to do. Unlike most of the GSOC projects proposed, it would actually be doable in the time alloted. Robert Ramey
_____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com
IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of vi ruses. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Hi Robert, Unlike most of the GSOC projects proposed, it would actually
be doable in the time alloted.
I've done my best to make sure that project ideas are realistic in scope, and I think that most proposals have been (more or less) reasonable in ambition. If there are any that you feel are obviously over-ambitious, I'd certainly appreciate knowing. Please keep in mind, that the yardstick I've been using to measure "doable" isn't the same as "can be accepted into Boost". I don't think we've ever had a GSoC project finish in August and be part of Fall release. It's seems to be 6+ months for extensions, 1+ years for libraries. The reason for this is an entirely different discussion that's well beyond my control, so let's steer clear of it for now :) Andrew Sutton andrew.n.sutton@gmail.com
On 3/23/2010 8:02 AM, Andrew Sutton wrote:
Hi Robert,
Unlike most of the GSOC projects proposed, it would actually
be doable in the time alloted.
I've done my best to make sure that project ideas are realistic in scope, and I think that most proposals have been (more or less) reasonable in ambition. If there are any that you feel are obviously over-ambitious, I'd certainly appreciate knowing.
Please keep in mind, that the yardstick I've been using to measure "doable" isn't the same as "can be accepted into Boost". I don't think we've ever had a GSoC project finish in August and be part of Fall release. It's seems to be 6+ months for extensions, 1+ years for libraries. The reason for this is an entirely different discussion that's well beyond my control, so let's steer clear of it for now :)
Last year's Fusion GSoc project (an extension) is one of the most successful projects thus far. We are very pleased with Christopher's work on it. Now, I consider Christopher an active maintainer alongside Dan Marsden, Tobias and me. Porting Fusion to C++0x is not a trivial task and yet Christopher prevailed and his work is no less than stellar. He continues to be active with Fusion development to this day, adding new features, back-porting his extensions to the codebase, providing user support, etc. I'd say this is an exemplar project. And, make no mistake, the commitment extends far beyond the time frame of GSOC for it to be considered as really successful. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net http://www.facebook.com/djowel Meet me at BoostCon http://www.boostcon.com/home http://www.facebook.com/boostcon
Joel de Guzman wrote:
On 3/23/2010 8:02 AM, Andrew Sutton wrote:
Hi Robert,
Unlike most of the GSOC projects proposed, it would actually
be doable in the time alloted.
codebase, providing user support, etc. I'd say this is an exemplar project. And, make no mistake, the commitment extends far beyond the time frame of GSOC for it to be considered as really successful.
This is my point. Just about all of the proposals are beyond what one can expect to accomplish in 3 months. Yet, the proponents seem to expect that they will start now with an idea and three months will have something ready to submit to boost. History, and my personal experience in software development tell me that this is very unlikely. So one has two alternatives: a) prepare to make a commitment way beyond 3 months b) or pick a project smaller than a whole new library. It's certainly not my intention to discourage anyone. It's just a fact of software development that finish a project to the level that boost demands is way underestimated. Any author of an accepted library can verify that. I look at some of the proposals, the questions being asked, and the experience of the submitters, I can't help but think that they are taking on a a task/schedule that will turn out to be undoable. The unfortunate thing is there are a lot of things that could be done which ARE in fact doable - like enhancements to existing libraries. Unfortunately, these likely lack the "sex appeal" that makes for a winning proposal. In any case, I would suggest that proponents of these project should consider that there is nothing like the feeling that your code is being used in 1000's of applications. And this feeling you will only get if a task is taken to completion. A proposal for a whole new library which ends up unfinished might be interesting and fun, but it can't provide the satisfaction and respect from one's peers that the actual completion of a task can. Just my 2 cents. Robert Ramey
Regards,
a) prepare to make a commitment way beyond 3 months
b) or pick a project smaller than a whole new library.
I certainly agree with everything that you've said, but there are some contradictory requirements. We may attract students by offering them opportunities to work on interesting projects, or we may get fewer by offering maintenance projects. I'm certainly willing to list maintenance tasks as project ideas, but not too many have been offered. It's also worth pointing out that Boost has actually been pretty successful at retaining students after August, despite the demanding requirement (or maybe because of). I think 40-60% of previous students are still contributing or moving their libraries toward review. I think that's a pretty good measure. To be honest, I'm not sure how to resolve these issues in any satisfactory way. I do appreciate the 2 cents, though. This discussion is helping me build a bigger picture view of the requirements. Maybe we'll do better next year :) Andrew Sutton andrew.n.sutton@gmail.com
participants (6)
-
Andrew Sutton -
David Bergman -
Joel de Guzman -
Robert Ramey -
Stewart, Robert -
Viktar Sialiuk