Team Development / Exporting stuff to text files

[Jerry Daniels]

Guys....

I can't believe you fellows are talking about libraries at a time like  
this. Sir Paul McCartney is going through a messy divorce and will  
have to pimp out the Beatles to El Jobso / iTunes to make it happen.  
He needs our support (McCartney)!

Jerry

Daniels & Mara, Inc.
Makers of GLX2
http://www.daniels-mara.com/glx2

IF YOU JUST TURN AROUND WHILE YOU'RE REMINISCING, YOU CAN SEE INTO THE  
FUTURE.

On Mar 9, 2008, at 7:36 AM, David Bovill wrote:

> 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
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your  
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution