TSS Asks: Client Side Meta Data Specification?

Discussions

News: TSS Asks: Client Side Meta Data Specification?

  1. In the J2EE world, there are lots of specifications managed by the JCP (http://jcp.org), primarily focused on the middle tier of the J2EE stack such as EJB, JMS, JCA, JTA, etc., with a number of standards focused on the client side (servlets, JSF, JSP). However, the standards for client-facing APIs are fairly open, such that as "standards" they're not enforced very much.

    For example, JSF is a clear standard (required by Java Enterprise Edition) but there's no clear requirement that mandates its use by a coder.

    There are also no standards focused on creating unique rich client GUIs integrating with server side, unless you consider applets or Java WebStart as standards. Indeed, why is there no CSC (Client-side container) that is responsible for specific functionality? What does the J2EE community think about this? Should there be such a standard, and what would be its functionality?

    Threaded Messages (19)

  2. Actually, if you look around, there is one. It is called ACC or "application client container". Obviously, there are no widespread implementations. Why? Because web-apps are now the bees-knees, I guess.

    I am sure that when people get sick of forcibly shoe-horning GUI state-machines into webpages using AJAX, we will see more and more client-side-container implementations.
  3. Laszlo a standard?[ Go to top ]

    It seems that openlaszlo is moving in the direction of a standard of their own.

    Write your UI once in openlaszlo, compile to many UI targets. If someone wrote a laszlo to java compiler, that would be interesting...compile to flash, dhtml, or java.
  4. Java is on timeline for Laslzo[ Go to top ]

    I can't find the link anymore, but when I first starting working with openlaszlo last year, there project timeline indicated a desire to do a pure-java version w/o the Flash for the client.

    Personally, I think one could talk about exposing the *.lzx files to the client and then we could have a variety of client implementations for interperting those (perhaps some could pre-compile JIT-style the *.lzx for that particular client impl.).

    Is OpenLaslzo can truly be an open standard, I think it has a lot of promise!
  5. Laszlo just added DHTML support[ Go to top ]

    Looks like OpenLaszlo already added (beta) support for a pure-DHTML client rendering in addition to their existing Flash-based client rendering:

    http://www.openlaszlo.org/
  6. I like the idea of a client-side container, I think it would be nice if it could provide services that for example maintained the client's model in check with the data held at the server. I have been having a discussion similar to this at
    http://www.theserverside.com/news/thread.tss?thread_id=39390

    As for the 'application client container' mentioned above, it looks to me simply to describe how to access your EJBs remotely.
  7. In the J2EE world, there are lots of specifications managed by the JCP (http://jcp.org), primarily focused on the middle tier of the J2EE stack such as EJB, JMS, JCA, JTA, etc., with a number of standards focused on the client side (servlets, JSF, JSP). However, the standards for client-facing APIs are fairly open, such that as "standards" they're not enforced very much.For example, JSF is a clear standard (required by Java Enterprise Edition) but there's no clear requirement that mandates its use by a coder.There are also no standards focused on creating unique rich client GUIs integrating with server side, unless you consider applets or Java WebStart as standards. Indeed, why is there no CSC (Client-side container) that is responsible for specific functionality? What does the J2EE community think about this? Should there be such a standard, and what would be its functionality?

    I think Java has a big battle on its hands if it wants to be taken seriously for web-based rich clients, for various reasons, eg
    • the size of the JRE (70MB! What's that all about?!)
    • excessive memory usage
    • intermittent hangs while 'the system just sits there doing nothing' (ie collects garbage)
    • 1970s summer research project look&feel by default

    The JVM was originally devised for platform independence, but it seems that that is only true now if your platform is a server. The client focus has completely disappeared.

    Compare this with eg Flash or XULRunner. Very light runtimes, capabilities to handle most use cases, focus on keeping the user happy, not satisfying developers egos. Occam's razor and all that.

    Regards
    Kit
  8. I think Java has a big battle on its hands if it wants to be taken seriously for web-based rich clients, for various reasons, eg
    • the size of the JRE (70MB! What's that all about?!)
    • ...
    In all fairness, note that the "size of the JRE" is 15 MB, not 70MB. The JDK for 1.5.0 is 60MB, not 70MB, but it may be what you're referring to here.

    That doesn't invalidate the point, but 70 MB is a bit of an exaggeration.
  9. I think Java has a big battle on its hands if it wants to be taken seriously for web-based rich clients, for various reasons, eg
    • the size of the JRE (70MB! What's that all about?!)
    • ...
    In all fairness, note that the "size of the JRE" is 15 MB, not 70MB. The JDK for 1.5.0 is 60MB, not 70MB, but it may be what you're referring to here.That doesn't invalidate the point, but 70 MB is a bit of an exaggeration.

    For download size, granted. But size on disk is 70Mb, which IMO is more 'middleware' than 'runtime environment'. Compare with size of Flash plugin. And unobtrusiveness. Java just has the perception of being BIG and HEAVY.

    Kit
  10. Download size vs. disk image size[ Go to top ]

    For download size, granted. But size on disk is 70Mb, which IMO is more 'middleware' than 'runtime environment'. Compare with size of Flash plugin. And unobtrusiveness. Java just has the perception of being BIG and HEAVY.Kit

    (yes, although instead of 'middleware' I would just label it as 'virtual OS' or platform...)

    Well, usually people used to be more interested in downloadable size -- disk space is less of a problem than network bandwidth. So while 70 megs is a monster (too bad big chunk of that are just weird encoding tables etc), that may not really matter all that much, esp. to actual end users. I mean, gee, I can't buy a simple device (like scanner) without a gig worth of useless bundle-ware being installed to my windows partition. At least JRE has plenty of (potentially) useful functionality for applications that run on it, especially in areas of internationalization and accessibility.

    It is true, however, that it'd be good to have bit more lean-sizing wrt JRE: Flash (etc) are impressive in their lean downloadable and disk image sizes.
  11. Interesting .. in '04[ Go to top ]

    That question I asked in '04:
    http://www.theserverside.com/articles/article.tss?l=RiA

    There are muti platform answers like Laszlo(Ajax/Flash), Tibet(multi) , ZK (XUL-Mozilla/DHTML) and single platform like XUI(java), XAML(WinFX / WPF) , Flex (Flash) declerative UIs.
    Are there others?

    The answer for me in '06 is that JDNC org chart needs help as they have regresed since '04, since A. Flower took over and the original developers left, they will be showing what they had in '04 w/worse design and worse codebase. Thank you Sun, may I have another.

    .V
  12. I would think that you could view Eclipse RCP or Netbeans RCP as client containers. I have not personally worked with either but they would be my first port of call when approaching a large client-side project.
  13. I would think that you could view Eclipse RCP or Netbeans RCP as client containers. I have not personally worked with either but they would be my first port of call when approaching a large client-side project.

    Both are great platforms for java gui applications, for example having support for plugins, higher level (when compared to swing) etc. But I believe there is still a gap when it comes to client-server applications.
  14. Too much variety[ Go to top ]

    This is the problem that has plagued User Interfaces forever.

    In the beginning, you were limited to a keyboard with 10 functions keys, ENTER, TAB, ESCAPE and CONTROL combined with a 80 x 24 black and white display, fixed font, mono-spaced display with maybe reverse video.

    With such a limited display domain, abstraction is not difficult simply because there is really so little you can do with the medium.

    Standardize on a few keys for navigating and accepting or rejecting a form, lay out some field and labels, and perhaps some form to form navigation, and voila! "User Interface"

    While some green screen forms looked better than others (maybe you use some - and | and + symbols to demarcate spots on the form, or reverse video on active fields, etc.), they are much more "functional" than aesthetic.

    Pushing on to reports, where you had green bar, 132 chars by 66 lines run on printers the size of washing machines (that would just CONSUME boxes of paper). If you were lucky, you might even have UPPER and lower case on the printer.

    For fancy forms, you laid them out and ordered them from a print shop by the pallette, then your coders spent a week making sure the forms lined up straight in the printer, that the text didn't overwrite the pre-printed graphics, and that the printer hit hard enough to get through to the 4th copy (pink for accounting, blue for shipping, canary for picking and white for the customer). Thankfully, we had advanced NCR forms rather than carbon paper.

    The point is since you had such a limited domain, abstraction was very simple. Even without any abstraction, it was very simple, but even with a modicum amount of thought, you can easily factor out the redundant bits from form to form or report to report.

    Today, obviously, the display mediums are much, Much, MUCH richer. Not only have we migrated from 2000 black and white characters on the screen to 1,000,000 16M colored pixels, but we also have not just keyboards but mice, buttons, button gestures (double click), button chords (left and right click, alt-shift-F1, etc), mice gestures (i.e. drag and drop), even audible input and output.

    So, the UI domain has just literally exploded in complexity.

    All of that "meta data" starts becoming very detailed.

    The closest we've come, I think, is simply pure, semantic HTML and CSS and JavaScript. It's more the limitations of CSS and browser incompatabilities that foil our efforts here than the actual platform. The overall design is pretty good.

    But as soon as I mention that, folks will say "But that's not what I mean, I want something simpler! Mo' Meta!". Of course you do! We all do!

    But you can not have "simpler" unless you start locking down your interface. "Green Screen" interfaces are simple, with simple interactions, so meta data is simple. HTML pages with sliding DIV tags, dancing hamsters, and asynchronous Javascript are NOT simple.

    It's a simple information problem. The amount of information represented by the meta data, and the amount of information required by client (in this case, say, a web brower, but you can say the same about a "rich client").

    Everything you "meta" out of the meta data becomes, basically, default behavior. The more meta you get, the more default you get, and the more restrained you get.

    Peoples desires for rich displays frustrate the meta data dreamers today. One mans meta data is another mans prison. "I can't do ANYTHING with this...".

    But anything "meta" that provides a rich enough experience to satisfy all comers ends up being hardly meta at all! Soon you're buried in detail that the meta data was supposed to free you from.

    So, again, HTML and CSS is about as close as its getting I think (mind this is only for actual rendering of information, nothing to do with actual logic). XUL and CSS are a similar toolkit.

    The key here is simply that CSS basically renders the actual data, the semantic HTML. So, your actual data being pushed back and forth, the HTML, is little more than the actual data necessary.

    Note, I'm only using CSS and HTML as examples. You could use XML and XSLT, or anything else.

    The essence here is simply seperation of the presentation and actual data. MV of the MVC.

    What it all boils down to, tho, is that if you want meta data describing your client applications, I think that this is simply going to be very application dependent.

    Any "generic" meta data framework is simply going to be too general to be much value overall. The meta data gets simply too complex and pretty soon you're wondering "why am I jumping through all these hoops when I can just write the darn code myself!".

    At some threshold of development, a meta data or meta framework will simply drop out of your code base through natural refactoring. If you have 5-10 forms, its arguable whether you need such a framework at all. If you have 1500 screens, then you should spend time making the creation of those screens as efficient as possible up front. But, again, these will be application specific, with enforced behaviors and look and feels.

    I have little hope that a meta framework will get a large following, and still be useful in actually reducing the amount of information that we need to maintain. Things like Java and Javascript, with their OO basis supporting refactoring and specialization, redoing that in some other not necessarily complete language seems kind of silly.

    When the meta data starts looking like Java (or any other HLL), you have to start wondering.
  15. JRE is client side container[ Go to top ]

    JRE is our container in client side. You can have your own implementation of JLS/JRE! There are lots of services provided by JRE including GUI based ones.
  16. I think browsers standards and HTML standards can be more rich than now.Forexample AJAX can be embeded with HTML component to work properly with serverside components.Also I think we should refine some backbone standards like HTTP protocol.
    As you know when html created there were no internet applicaton.From that day to now server \side programming growed but browsers technology didn't grow as like as serverside technologies.Nowadays internet applications and serverside programming could cover many requirement of organizatins but we need more powerfull controls in cleint side and I think it's the duty of the browsers.
  17. w3c standard[ Go to top ]

    The standard that could unify the burden of declarative client side UI ( Laszlo,ZK,XUI,XAML,Flex (Flash),...) is the following W3C specification:
    Web Application Formats Working Group.
    Unfortunately the specification should be available only at end of this year allowing creation of many other similar but incompatible declarative client side UI implementation.

    Best regards
    Luca Tanieli
  18. If you feel that classloader separation is a part of definition of such client-side container (just like it is for server-side containers), check out:

    http://mjar.sourceforge.net

    a project I started to play with such implementation - side-by-side classloader-separated services in the same VM.
  19. I do not see much support either from JCP or any open source vendor on the Desktop Client space (Eg. Swing Desktop client talking to App Server through a Servlet). Are there any standards already which will help us on this?
  20. We still don't get it...[ Go to top ]

    I'm heavily into this client container idea. If anyone is interested in working on something (maybe OS, but a client container may be better closed-source, at least at first), contacting me (my last name is my website).

    We still haven't wrapped our heads around what a client container could do. Ask yourself this: If J2EE is a container that provides all the necessary SERVICES for server-side development, then what SERVICES would a client container provide?

    OpenLazlo is real cool, and all the XML-based client languages are, um, interesting, but nothing around today is at the right level of abstraction to be something other than a repeat of Swing/Motif/DHTML, etc. Maybe a nicer package, like there were better packages for threads and transaction before J2EE, but it's not the great leap forward.

    Even J2EE is not as high a level of abstraction - we can now describe our applications in terms of web services and BPEL flows on top of them. What would a description of a full client app look like if you could describe a client based on available services?

    If I only had more time...