Re: Symphony in Python (was Re: [ba-unrev-talk] Continuation of Doug's Colloquium)
On Mon, 27 Jan 2003, Jack Park wrote: (01)
> These are all important points you make. (02)
Pleased to hear you think so, and thank you for the informative answer. A
few quick remarks: (03)
> It turns out that while Python, or even Ruby may be much closer to ideal
> (whatever that means) programming environments, many of us, I think Gregory (04)
ok. with Steven I d(id/o)n't know if it's that (higher-level) direction
that is preferred, or lower (such as c(++)), or, hm classic?-) like lisp. (05)
> Rawlins included, got started earlier with Java, and Java continues to stay
> under our skins so long as others continue to support it in the massive
> ways they already are. Hewlett Packard funded the development of DSpace at
> MIT (www.dspace.org), and the Apache Foundation keeps tossing enormous
> pools of useful (sometimes) stuff at us. IBM tosses tons of stuff into the (06)
i didn't know there's Java stuff from Apache too, thanks for the other
pointers as well. i do know and agreee that it's a strong point that there
has been this movement (no matter how irrational it may have been ;) (07)
> pool, and there is a free, commercial JVM available that makes Java
> programs run nearly as fast as C programs (wintel boxes only). (08)
i've been told that Java performance is pretty good on small(ish) embedded
mobile devices, such as latest phones, as well. haven't really tested yet. (09)
> Zope is the closet entity I can think of that matches the availability of
> raw stuff to use in our projects, and, get this, Zope may actually do it
> better! That's because, discounting DSpace, Wynona, and several other
> projects, Zope is nearly complete in terms of usable stuff. But, (tongue (010)
interesting to hear that you think so, as Zope is what we've been using
(basically just setting up with different products occasionally) for a few
years. (011)
> I remain (for the time being) convinced of the scalability of Java
> enterprise-class projects as compared with Zope. Doing that research, I
> discovered that an important bottleneck to Zope performance is its crown
> jewel, the ZODB. Of course, there are workarounds to that, some of which
> toss out entirely one of the nicest features of Zope. (012)
ok. i think there are other problems with Zope too, but that's a different
story. (013)
> Jython may not be the appropriate environment in which to implement an
> entire system; it's a pretty good way to script other systems, maybe
> competitive with javascript, web-ognl, and other such environments. It's
> known to be far too low on the performance scale to compete directly with
> either Python or Java for whole systems. (014)
true. exactly this scripting-like use is what it seems good for. for
performance reasons modules have been written in C etc. as you probably
know. (015)
> Finally, you say you would like to implement or participate in a project
> that implements Symphony in Python. Make it so! Hmmm, I wonder if there is
> a Java2Python thingy out there... (016)
hm. what would that do? (that Jython does not suffice to in this case) (017)
i'm currently paid to work on ohs-related stuff, don't know how Symphony
relates to that, but as this discussion is now quite technical, the thread
might fit on ohs-talk better? (018)
for a potential base of an implementation of parts of (both Symphony and)
OHS, i've been looking into http://gzz.info/ . we are currently writing an
article about its storage module (storm) that's inspired by the
Xanadu-model. i'm yet unsure about how well it would support Symphony-like
collaboration, or whether some other solution is needed there. (019)
gzz is written mostly in Java, with Jython increasingly on top, and C++
for performance critical parts like high end graphics (with OpenGL). there
might be parts in Perl etc. too, haven't looked that closely now. (020)
so i think i wont be working to implement Symphony directly, but would
like to have similar functionality in the systems we are developing.
(dunno if expressed myself sensibly there, has been a long&intense day ..
please mind the time difference :) (021)
> Jack (022)
~Toni (023)