Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Slashback

Slashback: Echo, Lunchbox, Questions 108

Posted by timothy from the summer-is-over dept.
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!"
This discussion has been archived. No new comments can be posted.

Slashback: Echo, Lunchbox, Questions More

Slashback: Echo, Lunchbox, Questions

Comments Filter:

  • Where's the DHTML? (Score:5, Interesting)

    by AKAImBatman ( 238306 ) * <akaimbatman@ g m a i l . com> on Thursday September 30, 2004 @07:05AM (#10392915) Homepage Journal
    Is it just me or do all the pages refresh every time you do anything? I've been doing some internal applications in DHTML lately and have learned the amount of stuff DHTML can do (even if you avoid some of the more browser specific stuff). There's little reason to refresh the page for every event.

    If you want to see what DHTML can *really* do. Look no further than DHTML Lemmings [193.151.73.87]. It's an entirely self-contained application that can run on your local hard drive [xs4all.nl] without the support of a server. The current level is cookied so that you don't have to start over when you close your browser. All parameter handling is done by parsing the URL with Javascript. In other words, there is ZERO need for a server.

    Less need for a server translates to less strain on the server. Less strain on the server means that your applications will perform faster for both the client and your company.
    • 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 possib
      • I don't think this is possible, because the ECHO framework is heavily dependent on server-side state information [...] but without DHTML (since there's no need for or advantage to it).

        Believe it or not, DHTML can still improve this situation. Let's take the tree control as an example. Right now the current state of the tree is pushed to the client. When the client modifies the tree, it gets refreshed. But why?

        Let's say we have a tree that looks like this:

        + ABC
        + 123
        + This is a test

        Using DHTML, the serve

        • ...so the interaction you describe (event -> server, update->client) requires at least two network packets. So sending the tree updates versus sending the whole tree is a really nominal savings -- maybe 30 bytes of a 1k frame.

          So making the + sign in the tree listing an html link which yeilds a new page with the tree unfolded really doesn't cost you much different in performance, and it requires much less smarts and compatability on the browser side.

          Now on the other hand, if you're text-editing a

          • All you need to do is scale it a bit. What if the tree had 500 items at the top level? Then the savings would be extreme.

            In the real world, however, the savings would be immediate even with the exact example I gave. The reason is that most pages contain sidebars, titles, helpful text, and other controls. All of that data adds up, and can often be 10K or larger. In the DHTML web application I'm working on, pages are regularly 70K+. Yet since only minor parts of the page change, the savings are significant.

    • Re:Where's the DHTML? (Score:4, Insightful)

      by los furtive ( 232491 ) <ChrisLamothe@gma ... minus physicist> on Thursday September 30, 2004 @08:44AM (#10393687) Homepage
      While DHTML Lemmings is a great example of the powers of DHTML, it is a poor example to contrast against a web application since it never needs to read/write from a db, nor communicate with a server.

      I do agree with your point though, although I haven't tried out Echo yet, the use of RPC via iframe, xml or whatever should help avoid reloading the page, and also decrease the effort required to maintain the state of the page (when done properly).

      Personally I've been using for this very purpose (and their excellent listgrid component) and have been very satisfied with it.

    • I'm going to confess to attempting to wget your lemmings sample so I can learn offline. What you've described is exactly what I want to do for a number of applications I'm working on for my local intranet, and from what I've seen so far, your example is a great place for me to start.

      I guess my only problem with it at this moment seems to be the necessary interfaces to the server to retrieve data. I've been partial to attempting to do server access (when required, say, on final save) in an iframe that's i
      • 1. It's not my code.
        2. Look at the second link I posted. There's a link to download the source, sans the graphics and sound.
        3. Pages communicate via a combination of cookies and parsing the URL parameters.
        4. To snag the graphics from the site, download the source code and try something like this:

        find . -exec grep level_image {} \; > temp.txt
        cat temp.txt | grep gfx | cut -d \' -f 6 > levels/gfx/gfx.txt
        cd levels/gfx
        wget -i gfx.txt -B [http://whateverthebasurlwas]/levels/gfx/ -nd
    • Echo does not make use of partial updates to pages using DHTML after a server roundtrip yet (and I must emphasize the word "yet" here, as this feature is one of the big ideas for 2.0).

      In the current version, when Echo is notified of a server-side change to the state of the user interface, it will update the client by refreshing whatever HTML frame has changed. The long refresh delay you're seeing is in no small part caused by the demonstration server being entirely overloaded due to /.'ing. (I've actually
      • Hi Tod! Thanks for replying!

        The long refresh delay you're seeing is in no small part caused by the demonstration server being entirely overloaded due to /.'ing.

        Actually, I got to it before it was Slashdotted. The page refreshes were fast enough, but not so fast as to be unnoticeable. Even if you manage to make the "flash" the user sees invisible, they'll still notice when their screen scrolls back up to the top. I used to save the scroll position before refresh on an advanced calendar control that I had
        • I'm 100% with you on moving toward using more DHTML. Though we don't do it yet, the basic Echo engine is very much capable of pushing partial page updates, as we use a hidden frame for client-server communication. And we can always automatically fall back based on browser type to refreshing entire pages should a particular environment not support or work well with the partial updates.

          On the "maintainable JS issue", I can't tell you how many times I've had to rebut arguments of "Echo uses JavaScript, Java
          • One question, were you seeing pages scroll back to the top after every page refresh?

            Unfortunately, I don't remember if they do and I can't check (for obvious reasons). Personally, that's not a hack I ever liked much. Especially since you have to set the location at the end of the page. This can cause the page to "jump" a little after reloading, making the flash that much harder to eliminate.

            I'm looking forward to you guys using more DHTML. :-)
  • "We're moving away from the page-based perspective of Web app development, which is great for viewing documents," Liebeck said. "When you start getting into apps, with forms and validation, the page-based model breaks down." He cited as an example an application that, if the user's entries into a form are correct, will take you to the next screen, but must return a new window and highlight the incorrect fields if the entries are in error
    Maybe I'm missing something, but the example Liebeck gives contradicts his statement - it IS a page-based model, and one of the oldest ones, at that.

    If he wants a REAL example of something that acts more like a program, he should get a gmail account and see how interactive THAT is.

    • Re: (Score:3, Interesting)

      by account_deleted ( 4530225 )
      Comment removed based on user account deletion
      • Yep. I wrote a script that generates client-side find-a-word puzzles, so you can click on the letters to mark them as picked or not, and click on the words in the list to "cross them off" - once its loaded, there is NO need to go back to the server to use the thing. And that was a hack one weekend "just for the fun of it".

        And a table viewer that gets 1000 rows at a time from the server in "data:data:data:data" format, parses them out on the client side and showing 25 rows at a time. Only when you go beyond

        • Comment removed based on user account deletion
        • Rather than having to parse the string on the client side, have you thought of using JavaScript Object Notation [json.org] when returning values from the server...JS treats them as objects right away. It's sorta like XML for JavaScript, and has been a standard part of ECMAScript long enough that all browsers support it just fine.
          • I return them as an array, with each array element set up in "data:data:data:data" format.

            Quickly served by the server (1000 records actually as quick as serving 25 records formatted by the server).

            Then it's just a matter of doing a split betwen the colons, and some javascript to manipulate the page to change the values based on whether the user clicks next or previous..

            I chose this as opposed to, for example, name=value, because that's more verbose, hence more time to send. I want speed and ease of codi

    • He *is* saying it is a Page-based model! He is saying there's a better way to do it than doing a page submit/refresh for a validation.
      • Comment removed based on user account deletion
      • All data still has to be validated on the server. I remember one of my friends making ths mistake almost a decade ago.

        He was running a server on a Windows box, so I showed him how, by replacing his page with a dummy page I wrote on his box w. notepad, I was able to get a command prompt...

        Then I asked him if he'd like me to change the parameters so that, instead of giving me a command prompt, it would run "deltree c:\*.* /y".

        Client-side is for presentation of data and user interaction, and preliminary che

    • You are missing something.

      He means that from the development perspective it's moving away from a page based model.

      In other words, the developer using the echo api codes their app much like any "normal" gui app using swing etc.

      The fact that its really page based underneath is nicely hidden away.

      We have been using the echo framework for over a year now and I can tell you its the nicest way I've found by a long way to develop web applications.
    • What I intended to convey in this statement was the difference between "page-based" and "non-page-based" frameworks. For a better explanation that isn't cut down to a soundbyte, take a look at this developerWorks article:

      http://www-106.ibm.com/developerworks/java/library /j-echo1/ [ibm.com]

      Another item worth checking out to better explain how Echo actually works from a technical perspective is to take a look at the "high-level technical overview" on the nextapp.com site:

      http://www.nextapp.com/products/echo/do [nextapp.com]
      • Thanks for taking the time to reply. I checked out the second link (the first one times out).

        It seems to me you're asking the server to do a lot more work than my approach, which pushes almost all the work onto the client machine. Mind you, that's just my opinion. I want the server to just send the data, and the client to burn its cpu cycles to display it appropriately.

        Mind you, I also subscribe to the theory that any transaction can be made stateless through proper design, such that it (the requested tr

  • Echo: what's with all the server round trips? (Score:3, Interesting)

    by Anonymous Coward on Thursday September 30, 2004 @07:08AM (#10392943)
    I picked a couple of controls from the Echopoint demo [nextapp.com] to look at:

    1. It takes ages to load. So what's it doing? Caching JavaScript?
    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?
    3. The tree control seems to default to 'not client side'. That's wrong - it should autodetect.

    Now maybe this is all some protest against me because I'm using IE and it all works client-side by default in Mozilla - but that wouldn't be very professional.
    • I picked a couple of controls from the Echopoint demo to look at:

      It takes ages to load. So what's it doing? Caching JavaScript?
      It's currently doing a live demo of a server melting under the /. effect.
      "The operation timed out while attempting to contact my-server-is-SO-hosed-and-so-is-my-demo.nextapp.co m"

    • 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 ClientDatePick

  • Framework for PHP? (Score:1, Interesting)

    by Anonymous Coward
    We need such a framework for PHP. How else can we put 6 calendar "controls" on the same webpage? WACT [sourceforge.net]
    seems to be something like this, but I think it needs more support...

  • echo rocks (Score:2, Interesting)

    by codepunk ( 167897 )
    We used it to build a few apps already and it really reduces development time. The best thing is you can build a entire app and never touch a html tag.

  • "Rich" == "Fat" (Score:5, Interesting)

    by IGnatius T Foobar ( 4328 ) on Thursday September 30, 2004 @07:28AM (#10393060) Homepage Journal
    "Rich client" is Microsoft-speak for "fat client." Don't let them define the rules of the game. They lost the browser war (yes, really, they did: they killed Netscape, but the goal was to prevent applications from moving from Windows to the Web, and at that they failed miserably) and now they're trying to take it back by relabeling the bloatedness of the conventional desktop as "rich."

    Sorry, I'm not buying it. There is no "rich." There is only "fat" (runs locally) and "thin" (runs remotely).
    • At my work they run Outlook Web Client. DHTML driven.

      Features include: cut'n'paste OLE style stuff, full RTF editor, collapsable folders, alerts, the lot.

      And all the Web designers running Mac Os X can access it 95%. They give the web client a big thumbs up.

      It runs fine over my VPN to home.

      So there is "rich" as in functionality. "Thin" vs. "Fat" came from having to do a local install. To access the Outlook web client, all you need is a browser, and not even IE.
      Really it's pretty sensational, go check i

    • Have you tried Flex?

      http://www.macromedia.com/software/flex/
    • ...they killed Netscape, but the goal was to prevent applications from moving from Windows to the Web.

      Well, sort of. Actually IE-specific Web applications are just fine as far as Microsoft is concerned. Especially ones that use .Net features that are unlikely to be replicated in portable browsers.

      Microsoft doesn't care which Windows-only technology people use as long as it's Windows-only.

      And by the way, it is possible to build new technologies that are as thin as the Web model, but that provide a much

    • "Rich client" is Microsoft-speak for "fat client." Don't let them define the rules of the game. They lost the browser war (yes, really, they did: they killed Netscape, but the goal was to prevent applications from moving from Windows to the Web, and at that they failed miserably) and now they're trying to take it back by relabeling the bloatedness of the conventional desktop as "rich."

      Sorry, I'm not buying it. There is no "rich." There is only "fat" (runs locally) and "thin" (runs remotely).

      Just for the

  • Competition (Score:3, Interesting)

    by jole ( 4348 ) on Thursday September 30, 2004 @07:43AM (#10393132) Homepage

    Echo has a wonderful model of writing web user interfaces. My company IT Mill Ltd [itmill.com] is the author of an Open Source lisenced (LGPL) Millstone User Interface Library [millstone.org] that is very similar (in model) to Echo. In my (biased of course) opinion Millstone provides developers with better UI components and more flexibility.

    Main difference is that Millstone UI components are not dependant on Web, but has been (as prototypes) shown to work also in Swing. When doing Web-development, Millstone provides flexibility of using XSL stylesheets (in addition to CSS) for themeing, which makes customization of Millstone UI easy and flexible.

    See the the online demo [millstone.org]. If you have any questions, please join our just opened discussion forum [millstone.org].

    BTW: In addition of being an Open Source project, commercial support is provided (by us) and currently Millstone is used (has been for 3 years) in very large commercial applications.

  • what's the point? (Score:1, Insightful)

    by Anonymous Coward
    I just don't get it... all of this talk about DHTML makes no sense. I can write a series of static html files filled with all kinds of nasty JavaScript that allows my "application" to execute without a server and with what comes close to being a "rich client" experience... but what is the point? All I have is a nasty mess of tangled script code that is nearly impossible to maintain. None of these approaches (DHTML, hidden IFrames, Echo, etc.) will ever match the rich client program paradigm in user experie
    • Do you really think google would use DHTML for gmail if it was a "scripting workaround", or a "a nasty mess of tangled script code that is nearly impossible to maintain". Even perl code can be made so that you can maintain it (slashdot pages are perl), so if perl can, everything can ... even some javascript code...
    • You can turn anything into a mess of spagetti code, even Python. DHTML doesn't have to be a mess. You just keep a seperation of concerns and you should be good to go. If you think that maintaining a heavy client is easier than a thin client, you haven't had to deal with rollouts to thousands of desktops before. If you want something easy to maintain you go with a thin client. You only use a heavy client if some functionality is not available in a thin client and this is becoming more true as time goes on.
    • Two things: 1) Server side communication is here to stay. You can't take the internet away. 2) HTML is the best format for design and display. It really is. You get a better design most of the time. It's alot more flexible than forms, and alot quicker, and alot easier to customize. 99% of this is due to , , and tags. If you ask an HTML designer, he'll cry about css and absolute or relative positioning but he's wrong. What widgets HTML lacks should be added, not bastardized in 10 of 299 XUL/XA

  • Take a look at Zope (Score:3, Interesting)

    by Colin Smith ( 2679 ) on Thursday September 30, 2004 @08:13AM (#10393346)
    If you're looking at Echo, you should also have a look at Zope as well. It's a lovely development environment, I can throw business stuff together in hours which would take days/weeks in VB and Java. Brilliant for RSI sufferers. All that forgotten stuff which used to end up as a VB app accessing an Access database installed on every desktop machine now doesn't.

    http://www.zope.org/

  • Agnostic Widgets (Score:4, Interesting)

    by LetterJ ( 3524 ) <j@wynia.org> on Thursday September 30, 2004 @08:25AM (#10393465) Homepage
    There are already several comments about how many round trips this uses even for changes in widgets, something I don't think should take a form post to do.

    I've been working with HTML Components/Behaviors to build elaborate interface widgets for my current project. By rolling up a bunch of code, complete widgets like drop down menu's can be put into place with a single tag.

    I'd avoided them in the past because they were IE only, but http://dean.edwards.name/my/behaviors/ (the same guy who did the IE7 compatibility stuff) has made it so the same component can work on Mozilla as well. As such, I've been looking for widget sets that can be used to build richer components.

    For example, I've got an HTML behavior for text boxes that adds an attribute of "validationrule". That behavior invokes the appropriate rule when the text box's onchange event is fired and warns the user (by invoking my "message" component's display_message() method) if the contents don't validate according to the rule.

    Does anyone know of a resource for things like this? Richer client side widgets, possibly implemented as HTC/RBL components?
    • I didn't follow up on my original intent on that post. The project in the article is specific to Java, etc. Richer client widgets with simple declaritive syntax like HTC provides would make generating those interfaces easy in ANY language. The client and server can be agnostic to how the other is implemented.

      After all, for as much as people try to dress it up, building stuff on the web is basically text requests (http get and post) and data response (html and other files). If you funnel everything through

  • Echo looks cool, but... (Score:3, Insightful)

    by WhiskerTheMad ( 765470 ) <whisker@@@whiskerscorner...com> on Thursday September 30, 2004 @09:23AM (#10394167) Homepage
    What about XUL [xulplanet.com]? I took a brief look at it a few months back, and it looked pretty good-- but I decided to wait until they had a developer GUI ('cause I'm a lazy bastard :) How does echo stack up to XUL, or would that be comparing apples to oranges?
    • which XUL? That's the rub. And the whole point of webapps is the standard client with the HTML layout. I've written XUL apps and shipped mozilla with them, but I end up using just a couple widgets on top of HTML. Expand the HTML widget set!
    • It's comparing apples to oranges in that Echo is a API built on top of the base language (html) where as XUL is just the base language. XUL really needs a set of librarys on top of it to add calendar/date functionality for example.

      My advice (as someone who has only briefly looked at Echo but developed 2 fully fledged XUL apps) is that if you want to develop a rich web app now, use echo or something similar. It has more browser support, and the clear APIs will stop endless frustration/banding your head aga
  • Monolith, which has been around for considerably longer than Echo, is looking for a new maintainer. [annexia.org]

    It allows you to create object-oriented web apps in C which compile into tiny servers (and I mean tiny - the web server fits into the L1 cache on most computers). But they come with all the usual features like a templating system, database access and so on.

    Rich.

  • You got to love the people in the IT industry... Let's see... Linux friendly... Web based... No roundtrips to the server for EVERY refresh of a control... Can make "rich applications" and "rich user interfaces" and "rich whatever"... Is object-oriented... Not dependant upon M$ or .NET... Try Flash! And Flash Remoting! (...OH, but its NOT open-source... go ahead change the SH to an ME and FLA** me!)

  • Drug Policy (Score:3, Interesting)

    by Alsee ( 515537 ) on Thursday September 30, 2004 @04:20PM (#10399026) Homepage
    Damnit!
    There were three questions on drug policy, and for some reason they cut the best one and left the other two. Specifically it was the one pointing out the indisputable fact that alcohol is vastly more harmful and deadly than marijuana, so why the hell is alchol legal while marijuana is illegal?

    It's a real bitch of a question for a polititian to directly confront, and I really wanted to see how they each handled it. The only options are to come out for legalization, to blatantly lie, to blatantly weasle out of the question, or blatant hypocrisy.

    Well, I guess there's one other option, to come out for prohibition of alcohol. Chuckle.

    -
    • And I like how no question about securing the national borders (which neither major candidate has talked about) made it through the /. filter.

      And, of course, the question relating to traditional family values went down in flames. Apparently, ya just can't have that shit here on /.
  • If you really want to see the power of DHTML have a look at a demo framework I have created http://tahpot.homeip.net/wp_blog/index.php?p=6

    In reality there is nothing stopping the development of web applications that replicate the usability of traditional desktop applications, but have the power of large connected databases.

    If you want to look at some good resources checkout:
    www.bindows.com
    www.netwindows.org

    The power of web applications was hinted at in the first dot com era, but it is actually a viable r

Slashdot Top Deals

The most difficult thing in the world is to know how to do a thing and to watch someone else doing it wrong, without commenting. -- T.H. White

Close