[udig-devel] Re: fun on trunk: socket plugin does what? and draw2drender

[Jesse Eichar <jeichar.w@xxxxxxxxx>]

On 11-Aug-08, at 10:30 AM, Jody Garnett wrote:

Jesse Eichar wrote:

Addressing the point we are making developers learn 2 APIs.  That is absolutely true...  However the counter argument to that is that they may not need to learn commands for a long long time.  I still haven't for example and commands have been around as long as I have (4 years now).  So having to learn commands is not a forgone conclusion.

Jesse

Oh I see the difference in viewpoint.

From my perspective I have seen two RCP projects strip out everything from our ui plugins in order to fold udig technology into their application "cleanly". I expect a lot of the work we can get for uDig based development will involve this kind of interaction so I would like to arrange some options other than forking and post processing..

With that in mind a couple of thoughts were obvious to me (my thoughts may still be wrong as commands and menus are a difficult area):
- no top-level menu contributions (contributing to views and context menus should be fine?)
- contribute commands and handlers
- allow RCP customers to refer to those commands in their own applications and perspectives
- the net.refractions.udig.ui plugins would get a bit thicker as it starts to include xml code putting everything together

I agree with all these points completely and even more since I have recently integrated uDig into an existing application as a set of features and not as a basis for an application.  So I really really appreciate these issues.  If you notice some changes I made was to reduce the role of the ActionbarAdvisor even further.

However:

• Even when we have moved uDig to commands you still don't necessarily need commands to integrate with the "future" udig.  You need to know how to configure then in XML perhaps but not implement them or really even use them.  I know since I have integrated uDig into the existing SpatialDataIntegrator project
• The Socket API does not affect the UI or other applications except that you need to know how to turn it on and off and configure it using the Preferences API, which is an established API.

My big worry is that in the good intentioned attempt at making everything integrate with other applications we will unnecessarily complicate our API because the added flexibility is not necessary.  So far you have argued many good points and have almost convinced me that my solution is correct.  (I was originally must more in favour of commands and IHandlers than I am now) :-).

Here is what I need.  An example of how the current solution makes integrating with another application more difficult.  Or how adding an API of one 2 method interface complicates the life of developers...

Here is my mind game:

• Let us assume that developers have to learn the commands API for some reason.
• The question is how do we use commands in my API...
• We could use the command extension point to find commands 
• this won't work because we have very strict requirements on what the command and its handler can do and how it must behave
• we can't accept any command in the system
• We could create a specific category for our commands and we ignore all commands that are not in that category...
• This is not great because we are relying on convention to contribute commands and careful reading of documentation
• We could define our own extension point with documentation explaining how the commands must be implemented and what parameters are passed in. 
• We now have some of our own API plus potentially confusing javadocs on the purpose of the commands
• An alternative is to have a new Extension point that takes:
• A MessageHandler class it is a Simple interface, 2 methods and realistically we can get rid of one of the methods because of the next point.  (So lets say 1 method)
• and the protocol header for choosing the correct handler (very simple to document)

Obviously my mind game is heavily weighted towards my solution, largely because I don't know the command API very well at all.  If you can please come up with a "realistic" way we can use the Command API and I will try to weigh the options in a fair way :P.

Jesse