David, As Richard said, I find stacks the idea binary data storage container, too. In fact many of our customers apps have stack based document files, which have zero business logic and in fact are never seen by the user. Works great. And, if for some reason you need an intermediary format, one can quickly be written to convert a stack to whatever format is needed.
XML is a bit problematic as a file format. It's much better as an intermediary storage format, but not necessarily a good idea as an application file format. Just look at Microsoft's Open XML format who's spec is several thousand pages long, and one can quickly see it's not a very efficient document format. While it might be great for exchanging data between programs, it's slower to load and more difficult to navigate. I also agree with Richard regarding our joint property inspector project. The problem wasn't version control at all-- nor was it our ability to communicate with each other. It turned out it took more time to talk about the project, than just create the damn thing. So, now there are 3 different free property editors, one by each of us. Anyone can take their pick. That said, IMO, talking wasn't a waste of time. And I really don't know what "talking through improving shared code" means. Sounds like I may need to light some incense? You also say, "Code written by an individual remains that - individualistic. Is this not one of the reasons why there are so few commercial quality community created libraries or components?" I don't think so. Frankly, I believe there are 4 main reasons for a lack of quality libs: 1) Rev's already verbose language pretty much negates the necessity of generic libraries. Can you state a library one would want which isn't already created? Many less verbose languages end up creating vast libraries to do things like string handling, media management, etc.. Most of this is already handled in Rev by the engine. 2) Adding commercial grade generic libs and objects, like a great grid object, currently isn't really feasible via scripting, and is also not possible using externals. Until there's a real object model in Rev, this continues to be a problem. No number of cvs or open source programmers can fix this. 3) Small community of Rev experts willing to work on libraries. The number of Rev users is very very small. Even smaller is the number of Rev expert programmers, who could tackle difficult library chores. This isn't the case with most Open Source projects, like Gimp, Linux, etc.. 4) Very difficult financial model for even Open Source developers. I don't know of any company (like Sun, Google, IBM) who would consider sponsoring a Rev Open Source development project. Even for commercial Rev tools, the market is severely limited, and I'm not aware of a single developer who makes a living selling into the Rev Tools market. I suspect Jerry Daniels is probably the closest, and I know he has several ongoing gigs which keep him whole. Years ago, Altuit tried marketing products in this field, and we ended up selling all our tools to Rev as we didn't think the ROI for us was worthwhile. I'm not sure Rev is the ideal Open Source collaborative application environment. That said, I do plan on releasing sometime soon "Rockets CGI Editor" which will work with the free version of RevOnRockets. Though neither are collaborative in the way you are thinking, they should be quality products and free to use. -Chipp _______________________________________________ use-revolution mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
