1Ferry Kranenburg  25.11.2010 8:26:42  Xpages in the client only for non-critical applications, like intranets or archives.

Our company Intranet is written in Xpages and is accessable from the internet by logging in first. Our users do not complain when they open this from the notes client. It sure takes a while before it opens but the users won't have to log in the system.

XPages in the client is somewhat limited too.

- Flash elements (like the xpages flash uploader from Mark Leusink) won't play in the client

- When the application uses the Xpages Extention library, it must be installed on the client machine.

But if you need your application to react quickly on first start in the client, I wouldn't recommend using XPages.

2Paul Withers  25.11.2010 9:30:15  I agree

One of the big strengths of the rich client is the ability to collaborate so effectively without having to open another piece of software. From that one piece of software users can access mail & calendaring, edit documents, spreadsheets, presentations, store the docuents in a Quickr, instant message colleagues if they have a query, set up activities AND use proprietary applications. If my proprietary apps all need to be local apps for XPages, I cannot see how I can recommend that customers use XPiNC. And that's a shame because it does offer much greater flexibility, a richer user experience, and reusability.

The only workflow applications I recommend to be used locally are where users require the information offline. The problem, as discussed, is ensuring they replicate immediately before and after any changes (and that means replication of both mail and applications). Even where users are in different locations, we tend to have on site servers replicating, and the users access the relevant server. For workflow, in my opinion, server is always safest and best.

If local replicas are used, as developers we also need to manage the risk and resolution of replication conflicts. That would be harder for XPiNC, where you can't right-click and check the Document Properties.

3Julian Woodward  25.11.2010 11:04:13  Not ready for prime-time?

The keep-a-local-replica option is applicable only to fairly simple and small applications, and is not a solution. Indeed, it barely even qualifies to be called a workaround, except under very specific circumstances.

XPiNC is a very good idea in principle, but it's significantly off the mark (so far) as a workable replacement for 'traditional' Notes client app dev.

4Wayne  25.11.2010 12:25:06  Convert XPages to Classic design elements

Yea, that's right. The allure of writing one set of code is nice, but the practical application as you have pointed out is not quite right.

XPages on the client is the wrong strategy.

Nathan Freeman previewed a conversion tool last week which takes Notes design elements and produces an XPage. I'm sure the reverse could be done, if... IBM/Lotus made those features available as Notes design elements. It would be easier, cheaper and simpler.

Domino/Notes is premier client/server technology. It didn't become bad just because web 2.0 is the current fad. Just as there remained a need for MainFrame computing, there still remains a need for client/server.

In fact there are many places where it might be preferable to cloud based solutions.

Put the features in the Notes Client, it's just the simpler way to do it.

5Erik Brooks  25.11.2010 13:30:01  Completely backwards

Yes, IBM has this TOTALLY backwards. XPiNC should simply be a browser to the server FIRST, and only fire up a local XPage renderer if the client is offline. The simple fact that you can introduce replication conflicts and have users with out-of-date-data simply because you converted a form to an XPage is horrible.

And performance on a high-latency connection has got to be abyssmal.

And what if your XPage calls LS/Java code that does something that can ONLY run correctly on your server? E.g. connect to a firewalled server, run a COM object, etc.

My understanding is that XPages do get rendered slightly different when rendering with a target of the client vs the browser. E.g. the escape key is bound to close the entire XPage tab, your ID is obviously used so you don't need to log in, etc. But there's no reason those capabilities couldn't be driven from the server's renderer instead of from the client's.

Honestly if IBM would just add the XPages renderer to DOLS (it's ridiculous that they haven't) then you potentially don't even *need* the client. IE/FF/whatever is infinitely faster/lighter than the Notes Standard client on typical mobile hardware.

They should make this an INI, e.g. CLIENT_XPAGES_LOCALITY:

1=(default) Run XULRunner against server, unless client is offline. If client is offline run local client renderer.

2=Always fire up local client renderer

3=Never fire up local client renderer, throw error if server is unavailable

@4 - Convert XPages apps to legacy apps? Good luck with that.

6Darren Duke  25.11.2010 19:13:06  Indisputable facts

Sean does an excellent job of pointing out the issue and Erik (@5) does a good job of explaining the fix.

Right now XPiNC is all but un-useable. It is that simple. Proxies screw it up, the load times are unbearable and lack of official IBM Xpages apps make it look like another flash in the pan (which I doubt it is, but several customers have voiced this concern over the past 3 weeks to me).

Still IBM proved with the Notes 8.x load times that they 'can' do something about issues like these. Let's hope they 'will' do.

My guess is this has to be addressed otherwise Group's Transformer product is a bust before it hits the streets. With the amount of IBMers pimping this "converter" that may help with a tipping point.

7David Schiffer  26.11.2010 8:48:06  Run in NotesBrowser

I am not sure at this, but you could try to run your XPages App in the local Notes-Browser (not as XPiNC but as WebApp in NotesBrowser).

The negative aspect at this will be that there is e.g. no single-sign-on

Possible Solution? XPages in browser is quite fast and is really running on the server ;-)

Regards David

8Sean Cull  26.11.2010 9:36:29  Thanks for your feedback

@all thanks for your feedback

@1 @7 working in the browser within Notes might be an option, the biggest issue is single sign on and the fact that some organisations do not routinely run the HTTP task on internal servers ( which can obviously be addressed ). If you could open an XPage in a notes browser and be pre-authenticated that would be worth exploring - you might need to refactor the XPage interface for the reduced screen area

@4 Wayne, having worked with XPages for a bit I would be happy to move to 100% XPages for 90% of my Apps ( subject to it working in the client ). I think that there is no realistic prospect of IBM adding new functionality to classic Notes development. The remaining 10% would be such simple quick apps that the existing functionality is fine.

The distinction between browsers and fat clients will continue to blur with HTML5 and XPages seems the obvious way forward.

I want just one code stream, If I have a code module that sends emails I only want to maintain it in one language.

XPages is a steep learning curve but once your on it and you have some re-usable code it is not so bad and the potential is huge.

As I have posted before I do think devs need to be careful not to price themselves out of apps by gold plating too much as I have discussed here

{ Link }

Thanks, Sean

9David Leedy  26.11.2010 9:54:26  Local isn’t always better

Using LOCAL db's isn't always fast either. In my former company we made the decision to move a PIECE of one of our main apps (Sales) to XPages. Since the bulk of this apps users ONLY use it via replica's while remote/disconnected, XPages In the Notes Client seemed like the Holy Grail to us.

So I turned one small piece of the app into XPiNC and I'll tell you... It was often VERY SLOW the first time to open. ESPECIALLY from the users in the server which is the point of this post but ALSO from the locally disconnect machines!

It was at least USABLE from the remote machines but completely UNUSABLE for the clients connected to the server. The first time load could be 4-5 MINUTES! On things like Citrix and even just PC's.

Due to the amount of data in the APP Replication was NOT an option. See the remote people replicated small subsets... but the people connecting to servers had access to ALL the data.

So we ended up not deploying this mod to the server people - which was NOT FUN... So much for "Write Once work for both". To get it to the server people I would have had to move EVERYTHING to the whole browser.. a LOT more work... the whole idea was no need to Rip and Replace. Start Adding new features in XPiNC until we can EVENTUALLY convert the whole app. Running this piece from a browser off Domino was NOT an option because we didn't have, nor WANT, at the time to put the effort into a lading page / portal to be able to find this feature. We wanted it to work in the client as promised.

Erik and Darren's comments are spot on. Especially about DOLS.

If XPages in the Notes Client isn't designed better for speed - then there's little point in continuing to push that even as a feature. And if we lose that then we lost the "Write Once / Work in Both" selling point. And that's a big reason to use when people think of migrating to another platform.

10Steve McDonagh  26.11.2010 10:15:00  Well done Sean

Sean

I have only had a play with XPiNC and my inital reaction was "this is crap" however since it is not a show stopper in my org where life is either Browser or Client there was no driver for me to research futher as you have done.

Personally ,and this is just a thought, I think that XPAFES functionality in the client is a non-starter. Running an HTTP service on the client and expecting it to be as fully functional and speedy as it is being served on a "real" server is an excerise in futility.

It would be better if the xPage code was directly intrepreted by the client as a set of extended native notes classes and methods which were eval'ed by the client

I am watching this space with interest ;-)

11Bill Buchan  26.11.2010 10:19:12  Ouch

This has somewhat tempered my enthusiasm for writing xPages client apps.

I think its a case of waiting to see what the official IBM response will be before major investment happens.

---* Bill

12Sean Cull  26.11.2010 12:41:32  Clarification on the 14 to 123 times comment

Just a point of clarification on the 14 - 123 times banding.

The 14 times is the comparison between the data loaded by a brand new application which has never been loaded in any session ( 112kb V's 1609 )

The 123 times is the comparison with a Notes application that has been loaded during a previous session ( e.g. the day before) and has therefore been cached in the persistent cache used by Notes ( 13kb V's 1,609kb )

These ratios are conisitent across test machines

13Sean Cull  26.11.2010 13:08:06  An interesting thought

Someone just made this point to me in a conversation and I thought it was worth posting here.

In an pure XPage application ( as opposed to hybrid classic Notes / XPages ) it is a relatively simple matter to change the data source to point somewhere else.

If you had to have an XPage app run quickly but store the data on the server you could have a local XPage application with its data source on the server, similar to the approach you would use with a .net or sql client-server application.

You might even be able to make that an intelligent choice based on being able to reach the server ???? i.e. it would use the local nsf otherwise.

I am not sure it is a solution to the wider problem but it may help in some situations.

It also strikes me that as a classic Notes developer I do need to think outside of the classic notes box even more that I thought I did !

14Mark Barton  26.11.2010 15:04:36  Binary / Compressed / XML ?

Sean do you know if the X Pages 'framework' is sent down the wire compressed and in a binary format?

Did you have compress network data enabled? How much of a difference does this make?

15Sean Cull  26.11.2010 15:45:56  Compression works !

@14 Mark, the term "framework" is very much my simplification for something that I don't pretend to understand !

I believe that it is the compiled Xpages, Custom Controls and Java ? classes.

I have just switched on compression and it has reduced the figures by about 50%

The first load of the discussion forum drops from 1,609 kb to 820kb and the subsequent load from 24 kb to 16kb.

The first load of our XPage app drops from 9,361 kb to 3,604 kb. ( 62% reduction )

Compression definitely helps a lot but I do think that it is masking an underlying issue.

16Erik Brooks  26.11.2010 15:54:41  Not easily

@Sean/@13 - Even if you kept the data on the server you run into a major performance problem. With XPages in a browser your doc manipulation code will run on the server, which will be fast. XPiNC running local will also run fairly fast.

But if you're using XPiNC and it's connecting to the server then you're dealing with a ton of back-and-forth chatter to access your docs. An agent that processes 50 docs in 2 seconds on the server (or local client) would take a lot longer, even on a LAN.

17Peter Meuser  26.11.2010 19:26:11  Anybody SPNEGO experience?

@8 In my opinion being automatically authenticated in every app is one of the major advantages of the classic Notes world. With 8.5.1 Domino introduces support for SPNEGO based authentication againt AD. I have not tried it yet, but there seems to arise a broader support of this approach (see BlackBerry Enterprise Server, WebSphere...), which should solve at least the authentication problem.

At the end the importance of locally running apps will decline more and more. For example I spent the last year with integrating a Notes based CRM with a web shop system (Open Source/Tomcat based) for realtime data exchange. The CRM was run for years as offline/replication solution by international agents. Very early it becomes clear that this was no choice anymore with a central shop system connected through web services (and a fast growing data base, of course). We moved to Citrix XENApp to get the clients faster connected to the data without need to replicate. After some day-by-day experience with this setting (and after solving most of the issues of IBM's unfinished Citrix integration of standard client) I am more than ever convinced, that such and similar structed systems are in better hands of server-based systems with a web interface. Today I am not sure, if even a XPage driven Domino server is a really good choice for that purpose.

18Richard Moy  27.11.2010 3:15:31  SPNEGO Experience

@17

We have set up SPNEGO with Active Directory and it works very well. It works with both the real and fake IE8 and we use it with our Web Domino Application that we created for our clients. Rather than using XPages, we use pure Dojo with the Domino server. I have not tried creating XPages for the Notes Standard client, but from what I have read here I definitely do not plan to nor would I recommend my clients. The shift to the Standard client already created a total mess for my customers because a number of programming techniques that worked fine even until version 8.02 of the Basic client, no longer works either on the 8.5x Basic client or Standard client and crashes the Notes client. I loved the Notes Basic client because it is lean and fast. I have always voiced about improving the look and feel of the Basic client, but that is not going to happen so I do not bother anymore. Sadly, I question the future of the Notes client.

19Craig Wiseman  27.11.2010 17:48:50  Yeah, about the Notes client

@18 Hmmm.

Outside of the very small section of IBM that Lotus represents, I'm pretty sure IBM would be very very happy to have the Notes client go with Charon.

20Nathan T. Freeman  28.11.2010 3:12:19  GOFASTER=1

Sorry it took so long to join in the conversation, but I was on read-only restrictions by my family while on vacation for Thanksgiving.

@16 - "But if you're using XPiNC and it's connecting to the server then you're dealing with a ton of back-and-forth chatter to access your docs. An agent that processes 50 docs in 2 seconds on the server (or local client) would take a lot longer, even on a LAN."

And yet that's how 90% of Notes rich client applications are used today. The fact that it's XPiNC vs. Classic Notes doesn't really change anything about the amount of chatter needed for data rendering, except perhaps that view paging is more tightly controlled in an XSP app.

But your point about the performance GAINS in the browser context are well-taken. I bring this up a lot in conversations with customers who ask whether their apps will be performant in XSP. Yes, it's likely that supporting an equivalent number of users on a given server will require more hardware on that server, but is that more expensive than upgrading thousands of clients? Of course not.

The net results is that moving the application logic to run local to the data source results in a greater load on that ONE system, but also only ONE system you need to upgrade to improve EVERY user's experience.

@6 - "My guess is this has to be addressed otherwise Group's Transformer product is a bust before it hits the streets."

While I appreciate your concern Darren, I'm confident that our product management team has built a go-to-market strategy that has very little dependence on the use of XPages in the client.

"With the amount of IBMers pimping this 'converter' that may help with a tipping point."

I am, as always, happy to use whatever meager influence with IBM I might have to encourage them to address the shortcomings in their software in the correct order. But I must be honest, while I too find the start up performance of XPiNC apps to be a disappointment, I believe it would have a much better overall impact on the product as a dev platform for them to 1) refactor the Java API from scratch so it's fast and modern; and 2) address all the terrible limitations of view indexing that have plagued devs for the last two decades.

I'd gladly put up with longer app launch times in exchange for 6 to 10 times faster access to Domino data through the Java API. Just give us something we can put up as a loading screen so the user sees some type of progress message when opening the app for the first time, and then get to work on fundamentals that affect way more than load times.

All that being said, I have to admit that reading this post did get me thinking about what could be done today to make XPiNC apps go faster. I hadn't thought about the effects of network port compression, so it's great to hear that has the kind of impact that it does. And the point in comment 13 was something I was going to say as well -- the load times are really coming from the need to load the Java .class files from the application's VFS, and the fact that, as far as I know, the XSP engine has to load ALL the classes at start, even if it hasn't executed any of them. So deploying that as a local application for the client, even while pointing all data to a server-based repository, should be an effective strategy.

In fact, it's so effective that I've been contemplating adding it as an option in the Evolution Transformer for several months now. So it's great to hear that there's now an additional reason to do so.

I wish I had some other silver bullet ideas to make them load faster, but I'm afraid I haven't come up with any yet. XPiNC apps are essentially Eclipse plugins that use the XPages server libraries to render XUL and pass it to a managed plugin version of the Mozilla renderer. So many of the things that we OUGHT to do are whatever Eclipse developers do to make their plugins load faster. Alas, I don't know many of those, and what things I do involve a level of control that we don't really have with the XSP build process.

It should be the case that the second XPiNC app you launch in the client should load faster than the first, because more of the lazy-loaded plugins should already be active. It might also work if IBM added a similar "pre-loader" switch for XPiNC much like we have for Symphony now, where the rendering engine and the managed XULRunner instance could be launched in the background while the user is still starting up. But otherwise, I haven't come up with any cool tricks here.

If I do, Sean, you'll be the first to know!

@19 - Hrmm. It might be relevant that the Notes client is the single most prolific code in the IBM Software Group. No other product is installed on more individual processors than Notes. Eventually, someone might figure out that that has some value.

21Erik Brooks  28.11.2010 4:06:34  I think it gets worse

@20 - Shoot me an email, please, so I've got your GROUP email address. I'm working a PMR, that has become an SPR, that if not addressed makes XPages on the server have zero scalability. It will likely have a huge impact on your Transformer product when apps are run in the browser.

22Martin Donnelly  29.11.2010 2:49:04  can I have your application?

Sean,

We have been looking at potential issues that could affect performance in the way you describe, and would like to take your application so that we can benchmark any changes.

-M

23Sean Cull  29.11.2010 7:53:31  Thanks & On its way

Thanks Martin, really appreciate your help, a link to the download is on its way

Sean

24Alexey Zimarev  09.12.2010 11:10:22  Notes Client must remain

When discussing a possibility of giving up the Notes client many people don't realize that the Client now is almost the only way to have a working application combined with the data offline. Yes, we have DOLS but it is again quite resource consuming since it's nothing less than a small nHTTP process running on your laptop. What I love in our Notes base CRM system that I can work with it and check customer communication and tickets while being offline. Even now days you can't say you're always online when you need it. For example in the train from Standsted to Liverpool Street almost 80% of the time the 3G connection is either EDGE or just not available due to poor reception or tunnels.

So I would say I keep my CRM tool together with document libraries and mail as it is now without XPages simply because it works in a way I need it. If having one code line will mean giving up such a functionality I better give up XPages (in the Client).

25Sean Cull  13.12.2010 10:56:31  Production Data matchs my experiences

IBM have reported that even our large MOC application only took 3 seconds to open in their labs so I have delpoyed a vanilla copy of the 852 discussion template to a customers production servers to calibrate my findings.

This site has > 100 Notes users on a local enterprise class server < 12 months old. The test was carried out after most people had gone home on a Friday evening

Opening the 852 discussion database in XPinC for the first time in a Notes session took over 8 seconds. The same application had been opened a few moments earlier so was already compiled, indexed etc..

The data transferred was 889k so I think network compression was on.

It felt like a very long 8 seconds

I then opened the same application in the same manner from a server on another UK site, a fairly frequent occurrence - for example the CEO's office and his staff are based away from their server which is on a production site some 200 miles away. This took 16 seconds.

This is a $1.5 billion dollar turnover company with what I would consider to be a good Notes infrastructure.

Sean

26Sean Cull  18.12.2011 16:01:21  Update

I thought that I should post an update here.

We are now using the 853 client in anger and the performance issues described above have improved significantly.

We have yet to get an App onto a production site running 853 and XPINC so I will report back further into the future.