Feature talk


Helle oberstet,

I thought it might be a good idea to synchronize abit before developing ahead.

Im currently facing the problem that when using the @register decorator one can only specify RegiterOptions for the whole object passed to the register function.

Not only do I believe is that a violation of authority (the callee should decide what he needs, not the one registering it) but also quite constraining application design.

There are two solutions which come to my mind: either expanding the @register decorator with an optional options keyword arg or introducing an option @registerOptions decorator

which would correspond to the RegisterOptions ctor. I opt for the later solution because it results in a much cleaner code, compare:

@register(u"com.example.foo", options = RegisterOptions(details_arg = “details”, discloseCaller = True))
def foo(details = None):


@registerOptions(details_arg = “details”, discloseCaller = True)
def foo(details = None):


Besides that, we are currently using a custom decorator which allows for some more advanced features. It is meant to allow EJB-like application designs.

Using this custom decorator one can write code like this:

class MyService(object):

def foo(someArg):

def bar()

@Register(uri = u"com.absolute.uri")
def peekaboo():

service = MyService()

proxy = MyService.ProxyClass(session)

deferred1 = proxy.foo(42) # invokes “com.example.my_service.foo”
deferred2 = proxy.bar() # invokes “com.example.my_service.other_name”
deferred3 = proxy.peekaboo() # invokes “com.absolute.uri”


Im wondering whether you are interessted in these features Its API-breaking though you can always expose it as an extra/different decorator.

PS: Please put some more effort in pull-requests on github. Its very frustrating if one closes your pull-request with an oneliner consisting only of a handfull of words and then dont getting a response. Instead provide constructive criticism and leave the request open so that a solution can be found.