I think there is a difference in philosophy on the service contract tool here. Would you make the Content Repository accessible via the service contract? Seems like that doesn't fit. To me, the key difference is this:
- is your package going to serve a function that another package will also serve on the same system? Or is it conceivable that you will switch a live running system to running a different package offering the same functionality? If so, then use service contracts. For example, portlets inside the portals package (more than one portlet). Or the credit card processing package (you might switch from Verisign to... I don't know whoever buys Verisign?).
- is your package going to serve a core function that no other package provides? Or, if some other package provides it, it's not like you could switch yours out and the other one in easily? Think Content Repository. Workflow. acs-datetime. Seems like a straight dependency is the right thing to do there. The reason for the straight dependency is so you can start depending on the underlying SQL API and tables, too, not just the Tcl API. If we move too much to Tcl API dependence, we'll start to get bloated and lose the true power of SQL (eerily reminiscent of EJB architectures...).
- there is, however, a use for service contracts in these core packages. Think of 5 packages that depend on user-preferences. The user-preferences UI needs to link back out to those 5 packages, to provide relevant information in a summary screen. Thus, a reverse-dependency contract, called user-preferences-extension, is very useful to implement callbacks into these extensions.
