Team Development / Exporting stuff to text files

[David Bovill]

On 09/03/2008, Chipp Walters <chipp at chipp.com> wrote:
>
> 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.


OK

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.


Yes

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?


Well to bring out my 6 shooter - it means you don't talk about code you
supply a diff which does the talking for you.

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?


Only around 20! To be concrete the libraries I've had to work on in the past
due to a lack of community supplied libraries include:

   - Jabber
   - Google Data
   - Google spread sheets
   - Google docs, calendar, picassa etc
   - KML
   - Flickr
   - YouTube
   - iCal
   - vCal
   - Blog XMLRPC api's
   - del.icio.us
   - RSS / ATOM
   - JSON
   - OPML
   - ....

That is not to include more general stuff like outline, array, or specific
stuff like wiki text parsers, or all the open source web based projects I
would include in this bracket. Is there a reason why a wiki, or a blog is
not available for me to customise written in Transcript??? Because the
language is not suitable for the purpose? More suitable than php 4?

When I take a look at the early web applications I think that would be
pretty easy to write in Transcript, but its easier now to take an open
source project and customise it than rewrite it in Transcript. So I would
add to the above list all the web based projects that could be written in
Transcript / RevOnRockets but haven't been.

It is in my opinion the main disadvantage of using Rev - and the main reason
I dont use Rev for web based projects is precisely the lack of robust tested
community provided libraries and applications.

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.


Agreed.

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..


I wonder why. Those open source languages you mention started small with
only a few developers - Ruby? One of the differences was that those
developers worked together on code libraries that fed back into the
community - while Rev projects remain individualistic. It's not the only
factor - but Id argue it a factor.

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.


Agreed. Though in my oppinion RunRev would be worth far more than it is
today if it had pursued an open source model along the lines of MySQL six or
so years ago, or took a root similar to the one that FLEX / Adobe AIR have
taken recently - I suspect they missed the boat on that one.

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.


And I'd argue that without a change in the current way stack based community
development projects are supported there will be little in the way of
community contributed web applications for RevOnRockets. Which I think we
would both agree would be a pity. Maybe I could ask a direct question - take
a look at the libraries listed above that I suggested are missing - many of
them have been around for years and popped up