Team Development / Exporting stuff to text files

[Chipp Walters]

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