Thanks for filing the review request! I have the following questions and comments:

In general, the nodes in the services tab should serve two use cases: 

(1) explore and manage available services by expanding services nodes (e.g. DB connections to see and manage databases; Java application servers to see and 
manage deployed applications)

(2) use services by drag and dropping them into editors and visual designers (e.g. Web Services and Enterprise Beans)

--

The primary interaction the user can do with the C/C++ server node is to add/remove servers and maybe edit some connection properties. If the use case is 
really only about adding/removing connections, then there's no need to show it in the Services tab. It's enough to provide a manager dialog similar to those in 
the Tools menu where the user can establish connections and edit their properties. If it's a dialog box, it's also easily accessible from the Project Properties 
dialog, similarly to Java Platforms dialog accessible from the properties of a java application project.

Regarding the status notification, I would say much better notification would be if it's shown directly on the project node using the remote development.

As long as you don't plan to expand the individual connections to browse their content, I would say the nodes shouldn't be shown in the Services window.

Please let me know if you see it differently. Thanks!

I don't understand some of your concerns. Remote development *is* a service we're planning on
supplying and your argument seems to imply it doesn't belong on the Services tab simply because
its not complex enough.

We need some type of global view of servers. You're suggestion that it be shown via project
properties would mislead the user. The servers table is global, even though the binding is at
a project level. I'm concerned that making the table a dialog from project properties would
confuse the user by making him/her think the table was a project property.


> Regarding the status notification, I would say much better notification would be if it's
> shown directly on the project node using the remote development.

There will certainly be notification at the project level, but a global table showing server
status makes more sense. For instance, if I'm building my project remotely on server1, but
my make is a distributed make doing compiles on server1, server2, and server3, then I would
most likely have entries in this table for all 3 servers. If one went down, I'd want some
central location which showed that. Its not really a project issue, because from the project's
point of view the build is done on server1.

My original UI plans did have this server table in a different place (Tools->Options). The
review of the early plans suggested the Services tab and I feel its a much stronger UI with
the server list maintained there. Its easy to find and quick to check status (assuming we
have some type of visual status feedback in the table).

Yes, there's many resources managed by the IDE that could be called services. I would actually suggest to avoid the services term for this discussion, as the 
"Services" name was picked as one that the best matched the new content of the tab in the 6.0 release. It's not like we designed for it in the first place. Just 
look into the Tools menu, we have:

- Java Platforms (containing also Java ME emulators)
- NetBeans Platforms
- Ruby Platforms
- Libraries
- Servers
- DTDs and XML schemas
- Keystores

We could argue why are some items in the Services tab and other items are just in the Tools menu. We went through this when we cleaned up the former 
Runtimes window and changed it to the existing Services window. I basically summarized the outcome in the previous post. 

Now it looks like the primary interaction with the C/C++ servers would take place in project properties where the user selects servers for use with project. 
That should also be the place where the user registers a new server and potentially also removes no longer used servers. Just like "Java Platforms" or "Java 
Libraries" - the user interacts with its UI primarily through project properties of Java apps. Now the primary reason why "Java EE Servers" are in the Services 
tab is that the user can expand them and view deployed applications and potentially undeploy them. If there wasn't this functionality, the Java EE Servers 
don't belong into Services tab. They would be perfectly okay in the Tools menu.

Regarding the C/C++ server status notification, I tend to say this feature doesn't deserve the place in the Services tab. You can notify about the status where 
the server is used - in project properties and Project explorer. In Project explorer, it would be perfectly okay to show a badge next to the project node 
indicating that one of the servers isn't running. The project properties could then show the details (which server, etc.), the user could resolve issue in the 
dialog box.

The C/C++ server management would work well with a dialog box similar to the "Servers" dialog box accessible from Tools menu. It also needs a notification 
of server status on a project node. Otherwise the status would be hidden unless the user keeps switching between tabs. That would be the primary UI the 
user interacts with and IMO sufficient for such use cases.

If you expend the C/C++ server management use cases and solve it through the UI visible in Services tab, then yes, it may belong there. Just like if we 
decided to permit the user DnD Java Libraries from the Services tab into editor, or expand hierarchy of running apps on top of NetBeans platform. In that 
case we would add those nodes into the Services tab.

We'll remove the server list from the Services tab, so I guess we don't need any
UI review (no main UI components will be affected). If you agree, you can close
this issue...

Closing this review then. 

If you add an item into the Tools menu, it would also require a UI review, but I expect it to be quick. If that's the case, just reopen this review request. Thanks!