singleton means something in a certain scope.

A traditional singleton in Java has the scope of a class loader. In a 'basic' program this would lead to a single instance in the jvm. For webapplications, this isn't the case, unless some crappy unified classloader is used, so it has the scope of 'application' Each application gets his own instance of the singleton.

In Akka currently we mean with the singleton: cluster scope. But I can imagine that for certain services, e.g. a scheduler actor, it would be perfectly allright to give it a jvm/classloader scope.

So some of the possible scopes are:
- prototype (so no scope at all)
- cluster scope
- jvm/classloader scope

And I can imagine that you even want in some cases an 'operation/request' scope..

So imho we need to think about the different scopes in the system and come up with a much more powerful solution. We don't need to implement it for this task, but imho it is wise to know in which direction this very likely is going to evolve. So that we can make the right choices..

Updating tickets (#620, #679, #725, #750, #752, #753, #754, #763, #789, #870, #893, #922, #953, #954, #971, #977, #983, #985, #987, #991, #1026, #1045, #1051, #1060, #1061, #1084, #1098, #1099, #1133, #1134, #1135, #1136, #1137, #1194, #1225, #1226, #1243, #1245, #1247, #1248, #1254, #1261, #1300, #1317, #1391, #1412, #1791, #1793, #1901, #1908, #1911, #1912, #1913, #1914, #1915, #1916, #1917, #1922, #1983, #1987, #1996, #1997, #1998, #2066, #2077, #2105, #2117, #2133, #2143, #2149, #2151, #2152, #2153, #2155, #2157, #2158, #2159, #2160, #2161, #2162, #2163, #2164, #2165, #2167, #2171, #2175, #2176, #2177, #2180, #2182, #2184, #2185, #2193, #2199, #2202, #2204, #2206, #2207, #2209, #2210)