Team Development / Exporting stuff to text files
jerry at daniels-mara.com
Sun Mar 9 11:23:13 EDT 2008
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)!
Daniels & Mara, Inc.
Makers of GLX2
IF YOU JUST TURN AROUND WHILE YOU'RE REMINISCING, YOU CAN SEE INTO THE
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
>> In fact many of our customers apps have stack based document files,
>> have zero business logic and in fact are never seen by the user.
>> great. And, if for some reason you need an intermediary format, one
>> 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
>> is several thousand pages long, and one can quickly see it's not a
>> efficient document format. While it might be great for exchanging
>> between programs, it's slower to load and more difficult to navigate.
> I also agree with Richard regarding our joint property inspector
>> 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
>> 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
>> "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
> 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
>> 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
> 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
> 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
>> possible using externals. Until there's a real object model in Rev,
>> 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
>> of Rev users is very very small. Even smaller is the number of Rev
>> programmers, who could tackle difficult library chores. This isn't
>> with most Open Source projects, like Gimp, Linux, etc..
> I wonder why. Those open source languages you mention started small
> 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
> factor - but Id argue it a factor.
> 4) Very difficult financial model for even Open Source developers. I
>> know of any company (like Sun, Google, IBM) who would consider
>> Rev Open Source development project. Even for commercial Rev tools,
>> market is severely limited, and I'm not aware of a single developer
>> makes a living selling into the Rev Tools market. I suspect Jerry
>> probably the closest, and I know he has several ongoing gigs which
>> 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
> Agreed. Though in my oppinion RunRev would be worth far more than it
> 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
> 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:
More information about the Use-livecode