Kito:

Hello and welcome to the JSFCentral Podcast series, Episode 29, recorded in November, 2012. Today, I'm here with Ted Goddard who is the sort of head architect honcho at ICEfaces, and ICEsoft specifically.

Ted, thanks for joining me.

Ted:

Yeah.  Thanks for the chance to talk with you.

Kito:

Why don't you do me a favor and explain in more detail what your title is, and your role at ICEsoft.

Ted:

Yeah.  So, I'm the chief software architect at ICEsoft, and I look into the architecture of ICEfaces, ICEmobile, and ICEpush.  The idea there is that we just try to build some new and interesting web technologies that let people build web applications really easily.  And especially now with ICEmobile, we're trying to get ways to build mobile applications, but still use all the web techniques that everybody's familiar with.

Kito:

So, you guys have another product called ICEpdf, are you involved with that one at all?  Or no?

Ted:

Right.  Yes, we do have ICEpdf.  I'm not involved with that one.

Kito:

Alright.  So, I never actually got a chance to ask you this, Ted.  Before you joined ICEfaces—I'm sorry, ICEsoft, I'm sure everybody does that to you.

Ted:

Yeah.  No problem.

Kito:

Before you joined ICEsoft, what were you doing?

Ted:

Well, I was at Sun for a year.  At Sun Microsystems.  And there I worked—it was called Java Licensee Engineering.  Basically, you're fixing bugs in the JVM. 

Kito:

Really?  Huh.

Ted:

For the customers.  Yeah. 

Kito:

Sounds like fun.

Ted:

No.

Kito:

Okay.  And you've been at—how long have you been at ICEsoft?

Ted:

Now, I guess the last eight years. 

Kito:

Okay.  I thought it had been longer than that, but I guess that makes sense.  I think I met you at a JavaOne  like maybe six or seven years ago or something like that.  So, wow.  Okay.

Alright.  So, one of the first things I wanted to discuss was ICEfaces, of course, and the new release 3.2 just came out recently.  As most people know, ICEfaces is one of the leading JSF component suites.  And so, why don't you just first of all just give people who don't know sort of an overview about ICEfaces in general, and sort of what's different about it.  And then just tell us a little bit about the features or the changes and upgrades in 3.2.

Ted:

So, I think a good way to think about ICEfaces is to kind of go back to where it started.  It was right around the turn of the Ajax movement—in fact, just prior. Ajax wasn't quite named yet.  And then the whole Ajax movement started in 2004 and built up in 2005. And so, ICEfaces was one of the earliest ways to use Ajax with JavaServer Faces.  At that time, we were looking for ways to do web applications in a simple fashion, and writing Ajax by hand is always a bit tedious. 

And so, we identified the JSF standard as being the natural successor to Struts, which was actually quite popular at that time, too.  So, JSF hadn't emerged in its popularity yet.  And the technique that we use with ICEfaces is called Direct-to-DOM rendering.  And what that does is it renders into a document object model on the server, it allows changes to be determined in that DOM and propagated to the browser.

The effect for the application developer is that you don't have to hand-code any of the Ajax at all.  So, even within the JSF 2.0 standard now, which has the f:ajax tag, you still have to—if you just stick to what you get with the javax.faces JAR, you still have to really hand-code your Ajax.  You have to say "if Ajax on this event, I'm going to re-render the subtree." 

With ICEfaces, the directory DOM Automatic Ajax does that all for you.  So, it's really the easiest way that you can develop.  It's definitely the easiest way to develop Ajax and JSF.  I would argue that developing Ajax with ICEfaces is really the easiest way to develop an Ajax application, period.

Kito:

Hmm.  Okay.

Ted:

And then, the other really interesting features that's brought in with ICEfaces—it was there right from the beginning because—maybe because we even misunderstood what people meant by Ajax.  Ajax starts off with the letter A, which means asynchronous, so for it to really be asynchronous, it should be possible for the application on the server to update the page when it wants to, independent of a user event.

But this is Ajax Push, and with ICEfaces, Ajax Push has been integrated into it right from the beginning in a very simple way in that you just ask the application to render a group, and that group is usually a group of users.  And because all the change detection is done automatically by ICEfaces, when you render that group, the page updates are determined automatically and pushed via Ajax to all the browsers.

So, these two features mesh together in a very nice way.  That is the central architectural differentiator of ICEfaces, is this combination of Automatic Ajax, Direct-to-DOM rendering, and Ajax Push.

Kito:

Yeah.  That's a really great synopsis.  Before we get into the new features, I just wanted to delve into a couple areas in a little more detail based on what you just said.

First of all, I think the Direct-to-DOM sort of functionality is quite brilliant, and I think it is great the way it makes it so much easier to…sort of synchronize changes in the UI.  But I think one of the questions for me has always been…JSF is usually known to be somewhat heavy in terms of server side footprint, mostly with the component tree. And so, when you add the other layer of the Direct to—or the DOM nodes being managed on this server, what have you seen over the years in terms of how that affects the overall footprint of the application?  And what sort of changes have you made to make it more efficient over time?

Ted:

Yeah.  So, that's definitely true; there is an overhead.  And in some ways, it's kind of like the overhead that we paid when we moved from C to Java.  Where we had malloc() and free() and well, those work great, don't they?  But garbage collection is so much nicer.  But of course, you do pay at run time, sometimes, for garbage collection.

And yes, that's true also with the Direct-to-DOM rendering, you have that DOM on the server and then, there's a memory cost to have it.  And it's usually about 50 percent or perhaps, in some cases, equal to the size of the component tree in state saving. 

Some applications, depending on their characteristics, are dominated by the component tree; others are dominated by the beans in session storage.  So you sort of look at it like an extra component tree.  Now fortunately, there are things that have emerged recently.  For instance, with JSF 2.0, we have partial state saving, which helps a lot with the component tree persistent size in the session. And then, within ICEfaces, you can turn on the compress DOM flag, which uses Fast Infoset to store the DOM, rather than just representing it as…in memory as a Xerces DOM.  And that Fast Infoset, I was amazed.  I mean, Fast Infoset is really fast.  We're actually thinking of making it the default because it really adds very little…transforming an in-memory DOM into a Fast Infoset representation is almost no performance CPU overhead; but the size is considerably smaller.

Kito:

Nice.  Nice.  Cool.  Well, that's really good to hear.  The other thing I was wondering is…I love the fact that the Ajax Push stuff is built into ICEfaces, and the API for working with it, I think you guys have made it so ridiculously simple now, it's really well done. 

Now, having worked with other JSF component frameworks, specifically PrimeFaces and RichFaces, that both use Atmosphere for their Ajax Push… Where Atmosphere tries to—Atmosphere is a third-party framework for those who don't know, another open source framework that basically tries to make it easy for you to do Ajax Push by trying to find the best match between the capabilities of the browser and the capabilities of the app server you're using.  So, it may use web sockets, it may use long pulling, it may use some other mechanism depending on what's the best match.

And I found that it seems to be a little tricky to get Atmosphere to work all the time.  And that's just in my limited usage of it.  With ICEfaces, the Ajax Push always seems to work out of the box.  And my understanding is that's because you're always using long pulling.  Am I right about that?  Or are there different options?

Ted:

No.  That's right.  ICEfaces uses long pulling because it works on every browser, all the way back to IE6.  And it works on all of the mobile browsers that we support as well.  Atmosphere is a great framework.  Its role, in a lot of ways, is to fill the gap between Servlet 2.5 and Servlet 3.0 and then in the future, WebSocket APIs. 

With ICEpush, what we do is we provide two options for the asynchronous handling of threads.  I guess, this is a somewhat technical issue for working with push in an existing servlet infrastructure.  And as you know, when a request comes into an application server, a thread is needed to manage the servlet call for that request. 

Well, in Servlet 3.0, it's possible to hand off handling of these requests into a pool of request objects so that a single thread could deal with many incoming requests.  That asynchronous capability wasn't available in Servlet 2.5. 

This doesn't materially affect what you can do in terms of the push technology, but it affects the scalability.  Because if you need a thread per user and you have a thousand users, that could be a lot of threads. Some applications it doesn't matter.  There's a lot of applications where they're very—they're highly interactive with a small number of users.  In which case, thread per user is no big deal.  Other applications are less interactive, but with a great many users.  And there, you need this ability to handle multiple requests with a small thread pool, or fixed size thread pool.

So, with ICEfaces what we do is we have a commercial product called EPS that uses proprietary APIs for the various application servers.  For instance, WebLogic has long had a way to deal with this asynchronous handling of incoming requests, but it wasn't standardized until Servlet 3.0.  So, we have this commercial product, EPS, and then on all other cases for the open source variant, we just make use of the Servlet 3.0 APIs where they're available.

Kito:

Okay.

Ted:

So, I mean Servlet 3.0 is really coming into its own now.  It's available on all the current app servers; it's available in TomCat and Jetty and everywhere.  So, I actually think this was a good strategy because it simplifies—it really simplifies our code, because the Servlet 3.0 API is nice and it's standardized.  And when WebSocket is available in the browsers that people are using, then we'll just roll that into the ICEpush capability.  But as an application developer, you won't notice any difference whatsoever.

Kito:

Okay.  And for those that don't know, ICEpush is basically a separate product that does all the Ajax Push stuff, but it's integrated into ICEfaces, right?

Ted:

Yeah.  You can use ICEpush separately, and some people do.  Most people use it with ICEfaces.

Kito:

Okay.  And if you used it separately, how would you use it?

Ted:

Well, you just take the ICEpush JAR and add it in, and then there's an API that will look familiar to you from the ICEfaces API with—but instead of having a PushRenderer, you have a PushContext.  And then, you invoke Push on the PushContext.  And it will send a notification to the browsers in your groups that you've declared.

Kito:

Okay.  So I could use it with an old Struts application if I wanted to?

Ted:

That's right.  Yeah.  That's very easy, to just drop it in.  The new thing in ICEpush now is Cloud Push capability.  This is a mobile feature.  You may have noticed on your mobile phone that you can get a notification and that notification will drop down on the home screen for an application, even if you're not actually in that application. So, what Cloud Push gives you is instead of calling render with just the group name, now if you call render and then you pass in a notification message… If the user is not connected to the application at that moment, like they're not viewing your application in their browser, they're back on the home screen, then they'll get a notification using whatever service—whether they're on Android or iOS or Blackberry, they'll get a notification for that platform.

Kito:

Nice. 

Ted:

So, it's very little code changing.  And it gives you the ability to distinguish between some notification…. No, when you're doing a push, you don't always want the user to be notified if they aren't available.  So, you can choose in your application which ones are worthy of notification, and which ones are not.

Kito:

So, this may be kind of a detailed question, but how do you do that?  Because you're doing the long pulling on the client to say I'm here, right?  When the user switches to another application, you must somehow be able to notify the server that you're not there.  Right?  Or is it just that you won't get a response?  How does that work?

Ted:

Yeah.  It uses both, actually.  If possible, we try to send a message.  Because when the browser is hiding, at that very moment, you sometimes are able to send a message to the server and you can tear down the long pulling connection.

Now, that doesn't always work.  Because maybe at that moment the user just went into a train tunnel.  They didn't close their browser or anything, they've just suddenly gone offline, because we're talking about mobile cases.  And in that scenario, you attempt to send a notification from the server, but it's not delivered in a timely fashion.  And what that means is it gets stored on the server, and then the notification is sent via the Cloud Push mechanism. And it's actually a bit of work to figure out whether the user is there or not because one thing we've noticed is that bandwidth on mobile connections is fairly high, but latency is also really high.  So, just because you haven't heard from a user recently doesn't mean they're not there.  It may just be latency in their cellular connection.  So, ICEpush needs to adaptively measure these timeouts and when you're…it arrives at a timeout that's distinct for each user, and so when you haven't been heard from for a long time, then it will use the Cloud Push mechanism.

Kito:

Interesting.  Okay.  So, starting to wrap up sort of the ICEfaces stuff…  One of the complaints—or not complaints, one of the criticisms I suppose—in the earlier versions of ICEfaces was that you had a wonderful framework, a wonderful infrastructure, but not so many components out of the box.  I know you've made great efforts to fill in those gaps in ICEfaces 3.0.

Can you just talk a little bit about sort of the balance between the framework features and the components themselves?

Ted:

Well, there's an ICEfaces 3.2 just out this week.  There's a bunch of new components, and of course, as you mentioned, a lot of new components were added in ICEfaces 3.0.  In 3.2, we've got a new Google Map component using the Google Map 3.0.  And we've got a new tree component, and then, of course, a lot of little features added to a variety of the components.

In terms of framework features in 3.2, we have resource ordering.  You've probably noticed that when you get a component and it automatically includes CSS or JavaScript, it could very easily happen that that CSS—even though it's maybe targeted in the head correctly—is placed in the wrong order with other CSS that you use within your application. Where with ICEfaces 3.2, we let you add in a metafile that indicates the ordering of JavaScript and CSS resources, as they're included.

I should've talked about this during ICEpush, but there's also a new API added there for PushOthers so that you—it's very common in a collaborative application that you want to push to a group, but you want to push to everybody in the group but the caller.  Because some user has done something and they're in the group, too, but they want to push to everybody else. So, we've long wanted to have that API, and that was just added recently.

And then, the other kind of general feature in the ICEfaces 3.2 components are support for touch events, so that they would work well on mobile devices.  And that's kind of a…well, you say "is that an ICEmobile feature or is it an ICEfaces feature?"  And what we want to do is we want to span the whole range of possibilities because ICEfaces components are somewhat heavy for mobile devices in general because they're designed for desktop components.

On the other hand, the iPad is equivalent to a supercomputer from ten years ago.  So, the capabilities of these mobile devices are really catching up.  And what that means is that you can't tell people "well, you should only have mobile pages that are a certain size or that are of a certain complexity."  It's going to—the use of an iPad in an enterprise environment with a high-speed wireless network, always on, right there in the office is very different from a person with a mobile device out in the forest somewhere where they are transiently able to get a connection at low speed. So, the use of ICEfaces and ICEmobile on these mobile devices has to be able to span that complete range of very advanced functionality to very lightweight.

Kito:

Well, also if you think about the concept of touch, it's not only an Apple concept, right?  So, if you look at the Windows 8 devices coming out, they think the Windows 8 metaphor is okay, you have your laptop or desktop, but it's a touch screen.  And so, you want to be able to support those devices as those start to proliferate as well. Regardless of what you think about sort of the mixed desktop touch metaphor, someone's going to use it.

Ted:

Great.  Yeah.  That's a very good point.  The future of the desktop interface includes touch.  That's very important to incorporate that right into the base components. 

Kito:

Alright.  So, I think those are sort of my primary ICEfaces questions.  Well, what's next on the roadmap?

Ted:

Well, of course, all new components and optimizations for ICEfaces.  I think the most active very new work is going to ICEmobile. 

Kito:

Right.  Have you guys finished migrating all of the old components from ICEfaces 2.x, or replacing them?

Ted:

No, we have a library that came from ICEfaces 1.8 called icefaces-compat. 

Kito:

Oh, right.  1.8, right.  Okay.

Ted:

Yeah.  Those components won't be rewritten.  What we'll do is we'll just gradually add in…for instance, you know we had a tree in ICEfaces 1.8, but from ICEfaces 2.0 up until ICEfaces 3.2 we didn't have a tree component.  Well, now there's a new tree component.  So, rather than do…you know, we have a limited sized development team, so rather than do a lot of backporting work, we'll just be adding in new components.  Because we've learned a lot over time, how to build the APIs, and how to make them more JSF 2.0 friendly.

Kito:

So, if you were to start a new app today, could you use just the new components, just the ACE components?  Or would you have to use the compat components as well?

Ted:

No.  We expect people just to use the ACE components and maybe in some cases, stock JSF components. 

Kito:

Okay.  Okay.  Good to know.  Alright.  So, since most of your energy these days is going into the ICEmobile—or a lot of it, I should say—why don't you tell us a little bit about that?  There's some very sort of unique things about your approach.

Ted:

The basic idea behind ICEmobile is we want to make it easy to build hybrid web applications.  And what that means is an application that has both web and native device capabilities.  Now, I should point out that a lot of people don't need any sort of native capabilities at all, and also, ICEmobile is catering to that as a pure web application.  But the extended native capabilities are there as well.

So, let's just step back and look at—what are you doing when you're building a web application for mobile?  And what it means is that you have a server side technology for generating the pages.  And then, those pages are viewed in Safari or Chrome or perhaps Internet Explorer with the new Windows phone, on the device. Or with ICEmobile in the hybrid form, you're viewing them in an ICEmobile container, which is a container application that has a browser built into it, together with enhanced native capabilities.  For instance, that's how we do the augmented reality.

Or in the case of iOS, because there's sandboxing limitations on what is accepted by the App Store, you have the stock Safari on iOS together with an expander application called ICEmobile-SX. Now, if you have an enterprise agreement with Apple, you can build the iOS container and use that within your own company.  You just can't distribute that on the App Store.  So, the ICEmobile-SX expander for native capabilities is the App Store friendly native enhancement for ICEmobile.

Kito:

Fascinating.  So, basically it has to go through Safari, but it can do all of the stuff the other one can…or no?

Ted:

That's right.

Kito:

Okay. 

Ted:

It's a separate application that's launched back and forth between Safari and the ICEmobile-SX on the iPhone.

Kito:

Fascinating.  And so, if I wanted to make, let's say, a JSFCentral app, would I have to get enterprise agreement to do that?  Or could I just, say…is there any way I could still have my own branded app based on the ICEfaces extender?  Or do I have to use the current one as it…

Ted:

Yes.  You could submit your own variant of ICEmobile-SX.  I don't know that there's a lot of value to you in that.  I think the better approach would be to be satisfied with the home screen icon created from JSFCentral.  It would just have a button to add to the home screen and it would appear to the user as an app.  And then, whatever native capabilities, like Cloud Push, that you needed to make use of, they would just use ICEmobile-SX, because really, coordinating the whole process of submitting things to the App Store and managing all that, there is effort required to do that.

Kito:

Interesting.  So, you have those two approaches and there's also some mobile specific components as well?

Ted:

Yes.  Why don't I talk a bit about the capabilities of ICEmobile?  So, the first thing that you see is the theming capability.  When you display your application…say a button.  When you display your button on an iOS device or an iPhone, it will look like an iPhone button.  When you display it on an Android or a Blackberry, it looks like a Blackberry button.  And the way that we do that is we have device detection, and then the CSS is loaded according to the device theme that you have. I think that there's varying perspectives on what people want.  Some people want the web application to look like a native app; whereas other people want their theme to be their…say, their corporate theme or their own theme for the application.  And you can take either approach, but the built-in approach is that it automatically themes it to look familiar to users of that device, which I think is a good strategy there.

So the theming is kind of the foundation of the components.  And from there, we have a variety of layout components because mobile screens are small, so it's nice to have components that help you with building accordions or various panels that can switch in and out, and large and small views for the tablet view or phone view, or a desktop view. And then, there are components for selecting images from a carousel and panels and various components like that that you make use of.

Now, Geolocation is an interesting component because you sort of think of it as a native feature, but it's actually a built-in JavaScript API.  So technically, it's just sort of in the…conceptually, it's a native component, but technically, it's not a native component.  It's just an HTML 5.0 component.

And then, as we move from Geolocation, then we move into the actual native features where we have a camera component.  All you do is you put the camera component in your page, and then this will use the enhanced capability of ICEmobile to launch a camera on the device and capture a file.  Now, the file is then stored in the flash file system on the device.  And when the form is submitted, it's submitted as a multipart form containing your other form fields from your JSF application, as well as the bulk data for that image upload. And then, when you get the value of your camera component, you get a map that contains java.io.file object and some meta information, like the content type and stuff.  So, it's really easy to just add this camera button into your JSF application, and then you've got a photo-taking capability.  So, we have camera, still camera, audio recording, video recording, contact list access.  You could get the user to pick a single contact and that will go into a value. 

We have QR code scanning capability, which is actually kind of cool.  When you combine the ability to scan QR codes…so, there's a component for scanning a QR code, and then there's a component for generating QR codes.  You can actually build an application where you dynamically create a QR code, and then somebody with their other phone could scan that QR code and effectively transfer state between them. So, imagine you're in a meeting room and somebody puts up a presentation, but you want it to be a collaborative presentation.  So they could scan the QR code that they see on the screen, and that would automatically log them into your collaborative presentation so that they could add comments as you're giving the presentation, or ask questions.  Things like that. I think that this whole dynamic QR code together with scanning is interesting because it's another communication path between devices and applications.  So, that's fun.

And then, we move into the more cutting edge stuff, which is the augmented reality features.  And there in ICEmobile we have two flavors of augmented reality.  One is location based where you're able to put icons at GPS positions.  And you just move your phone view so that you're looking in that particular direction, and if the GPS coordinate places that icon in space in front of you, then you see it's superimposed on your camera view.  It's really easy to build an application because we have a JSF component for augmented reality.  And you just list the locations and then, the URL for the image, and the name.  It's sort of like a select component, is actually what it's similar to.  But it's an augmented reality component.

And then, the other variant, which is also similar—to the JSF developer—as a select component, is a marker augmented reality view.  And here—right now we're using the Vuforia toolkit from Qualcomm—you have markers.  And markers are kind of like a barcode, but they're like a very simplified barcode. And what the augmented reality view gives you is a three-dimensional object that's attached to that marker as seen on your table.  So, what it looks like is you're looking through your phone viewer and you see these holograms for the objects attached to the markers.  How you work with it as a JSF developer is…you create a wavefront object file, corresponding to the 3D object that you want there, and you just associate it via a list to which marker it is.

So again, very…it's almost like working with an image resource, but it's a three-dimensional object that you can use from a JSF application. Now that I'm describing it, it almost sounds bizarre. 

Kito:

It sort of does, but it sounds cool. 

Ted:

It's something we weren't thinking about it all in 2004, that's for sure.  But I really do think that augmented reality is a major new direction for computer user interfaces.  But I think it's really great that JSF developers can now play with this stuff.

Kito:

Yeah.  That's really cool.  I've been meaning to play with ICEmobile, you're making me more interested in actually making the effort.

So, one of the things I noticed is that ICEmobile now also supports Spring MVC.  And is that…could you use it with just Spring MVC? I thought it said like Spring MVC and JSP.  So, what does that mean exactly?

Ted:

Yeah.  So, that's a new direction we're taking with ICEmobile.  Because we realized that there are a lot of developers that either haven't begun using JSF yet, or they just have an application that isn't suited for JSF.  And so, with ICEmobile, Spring and MVC and JSP are on par with JSF in terms of what you can develop.  And so, we have a parallel mobile showcase in both a JSF version and a Spring version.

Now, the core capabilities of it are really in the JSP tags.  And those are just plain JSP tags.  You wouldn't have to use them with Spring MVC.  You could build your JSP application however you want and just use those JSP tags.  But of course, there's a lot of people using Spring MVC with JSP, I think it's a very popular way to build it.  So, in terms of building our demo, we wanted to illustrate the technique.  The technique is actually Spring MVC with JSP with JQuery, for doing Ajax in this application—we saw that as a very popular way to do it.  But we're going to be adding more samples of this kind with ICEmobile over time, really based on what people want to see.  So, if you don't want to use JSF, you don't want to use Spring MVC with JSP, let us know what you would like to use with ICEmobile. 

For instance, I think another very nice way to do it is plain HTML with…in my case, I also used Spring as the backend because it was convenient, but you could use it in any sort of servlet backend with a pure HTML ICEmobile front end.

Kito:

Hmm.  Okay.  Makes sense.

Ted:

And so, that kind of relates to…you were mentioning about various client side technologies that people are interested in.  Some people are doing pure HTML, maybe with AngularJS.  But you could do that with ICEmobile and take advantage of the native capabilities from the JavaScript API even though you weren't using any server side technology to generate the HTML, you're just serving it as files.

Kito:

Oh, that makes sense.  Yeah.  Definitely.  So, there's lots of possibilities there, definitely.

Ted:

Yeah.  We now have…because we had a lot of different technologies within ICEfaces at the beginning, and we've now split them out into ICEpush, which you can use on its own, you could use it with JSP or you could use it even with HTML. ICEmobile is carved out in a way that you can use ICEmobile just with HTML or with the ICEfaces integration.  You can mix and match all these different pieces in various ways.

Kito:

Right.  Now, when it comes to actual support, how do you guys…because I know you have like the enterprise versions of ICEfaces and I think that includes ICEfaces mobile. How do you support other platforms?  Like, if they're using plain JSP or plain HTML, is there like a straight ICEmobile support package that people can get or what?

Ted:

I'm not sure.  We don't actually have a customer yet using ICEmobile on its own.  Everybody so far is using it with ICEfaces because I think that's how they find out about it.  And I'm sure when—because there's actually a lot of people using JSP.  So, I would expect that some people would want just JSP, Spring, likely, ICEmobile support package.  And we could do that. 

Kito:

Right.  Yeah.  I guess if someone comes to you and says I want support, you're not going to say no. 

Ted:

No.  And if they don't want support on, say, ICEfaces, then there's no reason for them to pay for that.

Kito:

Right.  That makes sense. 

So, one of the things I did want to mention briefly was sort of a little spat, if you will, that you guys had—I think it was last year, wasn't it?—with the folks who developed PrimeFaces.  And we had Cagatay on this podcast last—I think it came out last month—to talk about PrimeFaces, but also to talk about some of these issues as well.

And initially, the problem or the controversy centered around the fact that some of the ICEfaces ACE components were derived from the PrimeFaces 2.x code base.  And Cagatay and the Prime people got mad and there was some back and forth, and all that kind of stuff.

So, I just wanted to hear your perspective on that just so people can kind of hear from you guys. I know most people have probably read the articles and stuff by now, but I thought I'd give you a chance to talk about it a bit.

Ted:

Well, one thing that was really good is I got a chance to meet Cagatay in person at JavaOne.  And he's really nice.  And I feel like we're kind of two parallel individuals with PrimeFaces and ICEfaces.  And we have the same mindset about…when we developed the technology and we want to innovate and create something fun for people e to use. 

I think we saw—with the whole scenario that you described—is there's really a lot of different perspectives on it.  And the technology perspective that is my inherent perspective is different from a business perspective or maybe a project management perspective.  So, certainly from a business point of view, you might look at…there's a variety of open source code bases out there, and there's a demand from customers to integrate these and make use of them together. So, why not just go ahead and do that?  And that's been done.  And there are customers that are happily using those capabilities.

And the downside of it is the technological innovation side—and that's something that both PrimeFaces and ICEfaces feel the same way—is that the greatest opportunity for innovation is for each project to build the best thing that they can build.  They're potentially working on integration of these technologies so that they work together, but the most innovation will come from new independent things, such as what we're doing with ICEmobile where it's all built in-house, using libraries that are not directly related to what the technology is itself. For instance, the QR code scanning does come from a Zebra Crossing library, but the JSF component that does the QR code scanning is completely built as part of ICEmobile.

Now, the good thing is that at the end of the day, there's certainly no material harm done to PrimeFaces by being integrated with ICEfaces…I mean, that code borrowed and used in there. So, the customers have benefited and the community has likely benefited as a result of that.  I think what was lost sight of was the respect to how a person…and I feel the same way about ICEfaces.  When you create a technology, that technology is a part of you, you've created it and you feel very strongly about that as a person.  And that aspect wasn't entirely respected in this business level integration of the PrimeFaces code into ICEfaces.

And I think in some sort of alternate universe, we might've seen where the two, Prime technology and ICEsoft, would've collaborated together in a business relationship, and the end product might've been very similar.  But because a business relationship had developed there, then things would've worked more smoothly.

Kito:

I see what you're saying.

Ted:

But because that business relationship didn't occur…well, things worked out the way they did.

Kito:

Right.  And unless I'm mistaken, the primary reason for using the PrimeFaces code was because you wanted to be able to take advantage of JQuery and JSF integration.

Ted:

That's right.  It was a rapid way to get at the JQuery/JSF integration. 

Kito:

Okay.  So, do you guys still use a lot of JQuery for your components now?  Or what's the story there?

Ted:

Yes.  ACE has a bit of a mixture of YUI and JQuery, but JQuery is the dominant technology within ACE right now.

Kito:

Okay.  Alright.  That's good, you wanted to get that out there.

So, you mentioned that you saw Cagatay at JavaOne.  I missed it this year.  Were there any particular highlights that jump out at you from the show?

Ted:

Well, I think the main thing to say about JavaOne is it feels like it's returning back to its glory days.  I think we had a bit of a rough spot in there where it went from being in Moscone Center to…you know, it was a really strong show.  And then, there was the whole Sun/Oracle merger, which just kind of shook up the organization of things.  And now, there's been a chance to settle it out and the show has gotten back into its old rhythm and it's a lot more vibrant now…and I think it was a good show this year.

Kito:

Cool.  Were there new technologies that you're particularly interested in?

Ted:

I think a big thing that's emerging is what you mentioned with client side technology on the web, first is the server side technologies.  So, we're seeing…and then, there are too many of these client side JavaScript technologies right now, so there will need to be kind of a settling out of that.  But I think that is a really powerful movement.  That and say, scripting languages with Ruby to build DSLs and that kind of thing, is a really interesting development.

Kito:

So, along those lines—I think this is something that a lot of us are looking at from a JSF perspective—is that it is still a server side framework, although, I don't think it necessarily has to be.  I mean, at least not completely to the level it is with the stateful component tree.

But JSF is about building a UI that lives in the client and the server currently, and these newer approaches are more about building the UI with straight up HTML 5.0 and JavaScript and then, talking to a backend via REST or something like that. So, what are your thoughts about that, in respect to a technology like JSF in the next several years?

Ted:

Well, there will always be a place for server side technology because the server is where your data is.  And there's some really compelling reasons for building the user interface on the server.  One is that the user interface can be tailored to what the server is able to detect.  The other is that it's very secure because it means that the server has certain components that it thinks of as input components and it's building a view.  Then the client is submitting data against that view, but you can't submit data that doesn't match what's shown to the user.

So, there was this really strong feedback loop in the application developer's mind where he builds what he sees is what you can do in the application.  And that is like a security feedback loop. When you say "oh, I'm just going to build this on the client, and then in the backend, I'm going to have a faceless service that can do all my stuff," you really have the possibility that a clever hacker can do something completely different from what was intended in the application. 

So, careful practices will allow you to have a very robust and safe RESTful service in the backend.  And in some cases, when say you have a developer who is just focused on doing that RESTful service, then they can easily make that secure because they're not even thinking about the user interface, they're just thinking about what that service should provide to anybody.

But that's often not the case; often, you have developers that are building an application and it's very dynamic as it goes along.  So, JSF is still really well suited to that. It's also very suitable to building tools around with JSF, because it's just got components and these components have a very strong type structure to them. So, as far as building highly interactive enterprise applications, JSF is right in the sweet spot for that.  And I think that it should remain as a server side technology for building those types of applications.

Where we see these client side technologies emerge, are applications that need very high scalability, but are simpler in the way that they interact with server side data. So, there's a place for all of this stuff.  At the moment, I'm not convinced that JSF should morph into a client side heavy technology.  I think it still should reinforce the server side capabilities—it's what it's really good at.

Kito:

So, one of the things that I've been thinking about in terms of JSF is if we were to allow—or have a little more focus on less state, more sort of like stateless component trees.  To me, that sort of—it at least alleviates some of the performance concerns, or at least in terms of the wait on the server.  But that doesn't make it any more fully client side oriented, per se. 

Ted:

Yes.  But then, you could at least use your JSF components to produce the page that you did your client side work in.

Kito:

Exactly.  And I think that would go a long ways…sort of making it the best of both worlds.  So, we'll have to see.

Ted:

Yeah.  Now, the problem there is still the input side.  Back to the beginning, JSP was perfectly fine at generating the page, but then, there's input.  And then, it was always kind of weak at input.  So, maybe there would be an interesting way to still run the input from a JSP—or from a stateless form through JSF.

Kito:

Yeah.  I mean, I would still want to do that, it's just that we may not need for the component to handle…to hold onto this state. 

Ted:

Yeah.  But if it's still processing input, and did the bean mapping…

Kito:

Right.  And the validation.

Ted:

Makes sense.  Yeah. 

Kito:

However, that's not going to happen in the JSF 2.2 timeframe…   Although, there's a couple things I need to push into the EG that are in my mind, just to at least get them vetted a bit. But do you guys have any thoughts on it?  At least it's not a major update in terms of ICEfaces, which is good.

Ted:

Yeah.  You mean in terms of JSF 2.2?

Kito:

Yeah.  Yeah.

Ted:

Yeah.  I think the interesting things there, especially, are the HTML 5.0 aspects for components—now you can easily use placeholder, say as an attribute.  We already have that in ICEmobile, but it would be nice to be able to just use a regular h:inputText and give it a placeholder; that sort of thing.

And then, there's some new stuff coming in there with Facelets, which is good because a lot of people do pretty crazy stuff manipulating the component tree by themselves.  But if there's more ways to use Facelets, even maybe dynamic Facelets in a very structured fashion, then that gives another mechanism for these applications that need a lot of variability in the component tree, but to not do it just by the component APIs, which can sometimes lead to problems.   

Kito:

Hmm.  Are you talking about the multi-templating features?

Ted:

Yeah.  And the Facelets, there's different sources for their Facelet resource handler so that you could…

Kito:

Right.  Could load it from a different location and everything. 

Ted:

Yeah.  And potentially, that could be from a stream from a database or something, which might be a nice way to build a dynamic application. 

Kito:

Yeah.  Definitely.  Alright.  I think JSF 2.2 is dated for some time next year, if I remember correctly.  So, it'll be nice to see that come out.

Ted:

Yeah. 

Kito:

Alright.  So, last question, Ted.  What's your favorite thing about JSF and what's your least favorite thing about JSF?

Ted:

My favorite thing is definitely the programming model where you have components and you can put your components in the view.  And then, you have your Java Beans, which are very cleanly separated from the components.  They use EL, which is a pretty nice simple syntax for binding those two together.  And that's pretty much it.  Then you've built your application.

I think the least favorite thing—and we've talked about this—is the statefulness.  And it would be nice to be able to build more efficient applications with JSF that didn't require so much state.  But on the other hand, JSF is really tailored to these highly interactive applications, which inherently do have state. So, it's a tradeoff.

Kito:

Yeah.  I wholeheartedly agree.  Alright.  Well, anything you want to add?

Ted:

No.  I think I'd just really like to ask people to come and check out ICEmobile with the new augmented reality features and all of the easy ways to build mobile applications using the web.  And try out the new ICEfaces 3.2 as well.

Kito:

Okay.  Alright, Ted.  Well, it's a pleasure as always.  And hopefully, we'll have you on again—probably next year there'll be something new to talk about. 

Ted:

Certainly.  That'd be great.  It's great talking to you.

Kito:

Alright.  Thank you.