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 <[EMAIL PROTECTED]> 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
[email protected]
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
_______________________________________________
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
