From: Alexei M. <al...@ca...> - 2008-02-16 14:33:57
|
Date: Sat, 16 Feb 2008 19:05:19 +0900 From: Jordi <mu...@gm...> Subject: Re: [Playerstage-developers] GearBox: a new approach to making robot software reusable Hi Jordi, thanks for the comments. I'm one of the Gearbox admins. let me try to answer your questions. > - If all the submitted libraries are independent between them, wouldn't that > mean a lot of code replication? Lots of drivers will be similar, etc. Libraries in Gearbox can in fact depend on each other. You can make your library depend on another one of yours or somebody else's. Absolutely no restrictions here. We've tried to make sure that inter-dependencies are easy to encode. CMake does a lot of the hard work out of the box and we've added a few macros to reduce the dependency checks to just a few lines. take a look at this build system tutorial if interested: http://gearbox.sourceforge.net/gbx_doc_buildsys.html Yes, there could be duplication. Standardization is not our objective. there have been many, many attempts in robotics to standardize frameworks, communication, ontologies, data types, etc. None of them have left a mark. So if we don't want to set standards and don't want to create a new framework, then what? We think that the biggest "bang for the buck" can be achieved by bringing about a set of libraries which: a) work -- we hope to achieve this "novelty" through peer review and wider reuse b) can be glued together in a variety of ways -- by requiring that they do not link to any particular glue code. These 2 objectives are challenging enough and it is far from certain that it will be a success. adding the objective of standardization to the mix would add to the challenge substantially and therefore reduce the chances of success. Having said that I do hope that some degree of commonality will emerge organically for two reasons: 1) having 1 or 2 working and reusable implementations of a particular driver or algorithm would discourage people from writing another 7 or 8 half-working implementations (the situation today) 2) placing multiple implementations side-by-side into the same distribution would make functional overlap obvious and some developers may decide to join efforts. Some of course will not, but in that case I doubt that any standardization committee could convince them anyway. > - Gearbox is intended to be used by frameworks or by people programming > robots. If the later, how it is any different use it from using any other > framework? right on the money! it is NOT meant to be a framework. submission of framework-like code is discouraged. what exactly is a "framework" is hard to define and can be quite subjective. our working definition is "the code which is used for composing pre-existing modules into a system". in most cases the classification is obvious, where not, we'll leave the decision to a public discussion on the mailing list. who's the user? -- a very good question. we think of frameworks as the direct "users" of Gearbox. the end user trying to build a system using the framework of choice will of course benefit at the end. our immediate focus is on the developers of the existing frameworks. that's why we sent the announcement to the devel list. :) > - All the implementations will be C++? (may not be an issue anyway) No official restrictions or even suggestions. choice of the programming language is listed as one of the freedoms: http://gearbox.sourceforge.net/gbx_doc_principles.html#gbx_doc_principles_freedoms Practically, there're limitations imposed by the choice of CMake for the build system. C, C++, Java are all easily accommodated. > - Couldn't third party developers take care of retired code of other > developers? Or simply improve the code if the license is open? All the normal open-source rules and practices apply. The original author chooses the license and and is in control of the copyright and the direction in which the source is headed. > Great idea anyway. cheers, alex makarenko |