Monday, August 17, 2009

Headless nightmare

It is considered as a proper design to separate *.core from UI. Such code is flexible and very easy to maintain. And exposes important functionalities to others, so they can adopt it and create amazing tool.

But have you ever thought what will happen if your code will be used by headless client? In Eclipse support it is quite common case - someone create a scripts which creates workspace, sets up preferenfes, runs validation, builds jars and deploys them somewhere. It's only a couple of minutes to write that kind of script. Extending Eclipse requires a little bit more time, but it is possible to f.e. start server from ant script!.

Great!

But headless ant is also very quick route to headless hell. Ant application is not aware that there is no UI. Other plug-ins also seem to ignore that fact. Various dialog try to appear and break the build (there is no workbench!). There is actually ant application which creates workbench, but is it really headless script then, when user has to sit and answer when prompted?

And what about you, dear Eclipse developer?
Do your *.core components work in headless mode? Are they protected against failed extension point initialization?

I do not have even idea how to solve this issue correctly. I do not even know what should I request from bugzilla. Should each Eclipse application has own bundle set? Should Equinox allow for UI/non-UI/more general plugin division? Each architecture change will require a lot of work in many plug-ins (some plug-in cannot be easily decoupled, because f.e. *.core exposes extension point which needs to be contributed by one (and only one) extension (which is currently UI dialog)).

Now something related to my previous post:
  • 10% of readers was able to find the route couse in less than 10 seconds (I thought it is impossible).
  • 60% needed more than 10 seconds, but less than 1 minute.
  • 10% of readers finished before stopwatch shown 2 minutes.
  • 7% was able to complete the quest in 5 minutes,
  • 7% asked for more time.
Chuck Norris also completed the survey. He was contacted by the code which asked for fix (-1 sec).

You all are in quite good shape :-).

Regards,
Chris

4 comments:

Antoine Toulmé said...

Just use the Job API to do long running processing while running headlessly.

Of course my core plugins run in headless mode, otherwise, what would I bother ? :)

Krzysztof (Chris) Daniel said...

Job API does not help. The issue is that f.e. extssh exposes extension point for authenticator which is used when password/login does not match and is contributed by UI.

Now when you try to import project, ant tries to display that dialog, which is impossible, because there is no workbench. So:
It's a bug that ant refers to ui plugin and it's a bug that extssh does not check if authenticator can be created.

Jacek Pospychala said...

curious...
and what happens if you contribute fake authenticator extension that doesn't display dialog?

Krzysztof (Chris) Daniel said...

Actually you can easily workaround authenticator by specyfying your login and password in psf file, but then you will be hit by exactly the same kind of issue in extssh.