Slashdot Mirror
Slashback: Echo, Lunchbox, Questions
TodLiebeck writes "The Echo framework, which is used for creating web applications that approach the functionality of rich clients, has received some significant updates since its last showing on Slashdot. The community-developed EchoPoint component library has hit v1.0 and now provides more than 50 components such as a chart container and a rich text editor. The recently released version 1.1 of Echo is now available under the Mozilla Public License (in addition to the LGPL). More information can be found in these two announcements on TheServerSide, and this recent article in the SDTimes."
shimmerkid writes "After seeing almost nothing about audiolunchbox.com in your recent story about the perfect online music store, I felt a little vindicated when I received an email newsletter from them claiming they have become the "largest independent digital music store in the world." They have added Beggars/Matador and Kill Rock Stars among others, promising a total of 500,000 tracks (at 99 cents a track for unrestricted 192 kbps MP3 and Ogg) by December, and over a million tracks in 2005. The best part is that they pay the artists 65 cents a track."
Noksagt writes "The 50 questions for Bush and Kerry that were moderated and commented on in a previous /. story have been pared down to 20.
Vote for 10 of them at The New Voters Project Presidential Youth Debate. You don't even need /. mod points--just a valid email address!"
More responsiveness & high load abilities == happier clients
More client side stuff == more memory load on the client, often disproportionate.
which can negate the whole "re-use our old PCs, thin client" thing. I implemented an LDAP browser in DHTML for the day-job a few years back. The drawbacks were
1) Netscape 4 support. It sucks, and it's got a whole raft of bugs with dynamic frames and UTF-8.
2) Memory consumption, in the order of 30 MB for the application. There was only a few hundred K of javascript.
More client side stuff == more memory load on the client, often disproportionate. [...] in the order of 30 MB for the application. There was only a few hundred K of javascript.
True. But I'm doing DHTML on a 256MB machine. It's plenty fast enough. You always have to pay attention to whether DHTML will help your application or hurt it. If you need a very high level of interaction, and/or find yourself having to pump large amounts of uneeded data to the client (e.g. a combo box with ~10,000 rows), then DHTML makes sense. Otherwise, plain old HTML may actually be faster and more client friendly.
1) Netscape 4 support. It sucks, and it's got a whole raft of bugs with dynamic frames and UTF-8.
Time to give that up. I don't know about anyone else, but none of the sites I run support Netscape 4 anymore. It's not only 10 years old, but it's been replaced by several newer versions of Netscape, all of which function just fine with DHTML.
Anyone who's still using Netscape 4 either has a VERY old computer, or needs their head checked.
Javascript + Nintendo DSi = DSiCade
It allows the server to communicate back to the remote app.
Nice lemmings post BTW.
[% slash_sig_val.text %]
I don't think this is possible, because the ECHO framework is heavily dependent on server-side state information. You really have to look at it as a more or less 'normal' Java application that happens to use HTML to display its user interface. You even write Echo applications much like normal Java applications.
What you propose would be the equivalent of a Java application that woul maintain all of its state information in UI elements, with everything running client-side.
The way Echo works it is not possible to do any processing client-side using Javascript/DHTML, since that would require transferring state information to and from the server on every action or event, ie: reloading all frames. This actually happens to be the way this all works, as you already figured out, but without DHTML (since there's no need for or advantage to it).
Your sig is mine
Personally I've been using domapi for this very purpose (and their excellent listgrid component) and have been very satisfied with it.
I'm a writer, a poet, a genius, I know it. I don't buy software, I grow it.
I picked a couple of controls from the Echopoint demo to look at:
1. It takes ages to load. So what's it doing? Caching JavaScript?
The Slashdot effect has killed our server. Demos have since been temporarily pulled.
2. The DatePicker and DateFinder controls require a server round-trip to change the month you're looking at! That's way behind the times. So what happened to whatever it was loading for 1?
The DatePicker/DateFinder are very old controls. They've since been replaced by the ClientDatePicker in EchoPoint (and there's also a similar component in the commercial Sierra tool).
3. The tree control seems to default to 'not client side'. That's wrong - it should autodetect.
The EchoPoint demo in question is just a demonstration of various components of EchoPoint. The developer would decide whether s/he wanted to use a client- or server-side tree; this feature would never be configurable by the user of an application.