Calling function ticket.get() for defined tickets in Agilo return an error.

[anonymous]

Calling function ticket.get() defined tickets in Agilo return an error. Below Traceback output from log:

2011-03-01 10:39:37,852 Trac[web_ui] ERROR: RPC(XML-RPC) Unhandled protocol error
Traceback (most recent call last):
  File "build/bdist.linux-i686/egg/tracrpc/web_ui.py", line 167, in _rpc_process
    protocol.send_rpc_result(req, result)
  File "build/bdist.linux-i686/egg/tracrpc/xml_rpc.py", line 108, in send_rpc_result
    xmlrpclib.dumps(result, methodresponse=True), rpcreq['mimetype'])
  File "/usr/lib/python2.5/xmlrpclib.py", line 1080, in dumps
    data = m.dumps(params)
  File "/usr/lib/python2.5/xmlrpclib.py", line 623, in dumps
    dump(v, write)
  File "/usr/lib/python2.5/xmlrpclib.py", line 635, in __dump
    f(self, value, write)
  File "/usr/lib/python2.5/xmlrpclib.py", line 695, in dump_array
    dump(v, write)
  File "/usr/lib/python2.5/xmlrpclib.py", line 633, in __dump
    raise TypeError, "cannot marshal %s objects" % type(value)
TypeError: cannot marshal <class 'agilo.ticket.model.TicketValueWrapper'> objects

[osimons]

Talk to the Agilo people. I won't support their reworked ticket system via RPC.

[Olemis Lang]

@osimons :

I agree with you, however, what's the recommended approach so that plugins will be able to serialize custom objects via RPC ... (e.g. serialization hooks)

Should we think about adding support for this ? I was wondering, it's not an easy task due to the fact that (+ random thoughts ;)

• Plugin knows what kinds of objects it handles
• Different RPC protocols should define different serialization rules for the same custom type
• so we have a matrix ... where does specific serialization fit ?
• ...
• At least built-in JSON-RPC handler can rely on JSONEncoder to do this ...

Two approaches come to my mind :

• Default object serialization strategy.
• Introduce "serializers", i.e. objects able to convert instances of custom types to a hierarchy of simple objects (e.g. strings, integers, lists, dicts, ...) that may be serialized in headless mode afterwards.

[osimons]

Replying to olemis:

I agree with you, however, what's the recommended approach so that plugins will be able to serialize custom objects via RPC ... (e.g. serialization hooks)

Should we think about adding support for this ?

IF your plugin replaces the Trac ticket system to the point where you instead of regular types use agilo.ticket.model.TicketValueWrapper to encapsulate the data, then I don't see why all plugins should change to accomodate this. It should be their code (or some other plugin) that provides custom logic for dealing with this - like for example:

• They can subclass str, int or whatever or use some mix-in or meta-magic to support their own behaviour while still letting the fields maintain their basic identity and return regular isinstance responses and be serializable as regular types?
• Subclass the RPC Ticket module and add a small conversion layer to each method, or perhaps provide a one-method accessor that for any result will 'unwrap' before returning to RPC?
• Let it just fail if they for some reason don't want to support RPC access to information for their custom ticket system by using external APIs (like RPC)?

Outside RPC scope, IMHO.

[osimons]

Yours too then, I suppose.

[osimons]

Aargh. Again.

[anonymous]

Replying to osimons:

Replying to olemis:

I agree with you, however, what's the recommended approach so that plugins will be able to serialize custom objects via RPC ... (e.g. serialization hooks)

Should we think about adding support for this ?

IF your plugin replaces the Trac ticket system to the point where you instead of regular types use agilo.ticket.model.TicketValueWrapper to encapsulate the data, then I don't see why all plugins should change to accomodate this.

I agree with you 100%. They should be responsible for implementing and manage the impact of changes introduced by that plugin.

I was thinking of other circumstances where these kinds of behaviors may be useful (and may also help'em to implement RPC support ... but that's a side efect ;). For instance, let's suppose component C defines RPC method m and returns some complex information and somewhere ticket data needs to be included, and also there are custom model objects of type CM (e.g. Trac resource) that need to be sent back and forth via RPC, let's say that except some fields (e.g. password, ...).

In that case probably it would be nice to specify how to serialize tickets and instances of CM once, and then include those objects somewhere in the object tree defined by the RPC result object (i.e. the data to serialize and send back to the client) and built-in components will handle the rest of serialization steps.

AFAIK, something like this is already available in .NET .

Outside RPC scope, IMHO.

Maybe you're right, but in the end all RPC flavors rely on (particular) data serialization rules (e.g. Hessian is a binary protocol supporting default generic object serialization + other features ...). So it's always the lowest layer of RPC solutions AFAICS.

It may also be an added complexity, but probably would be nice to have the opportunity of controlling serialization rules for custom types.

[anonymous]

In any case this wouldn't be a critical but a nice to have feature .

[osimons]

Perhaps the Agilo people could chime in if they have an opinion on the matter, but seeing protocols can be arbitrary we need to stick to lowest common denominator for the supported type system.

There is no point in serializing an object and passing it down the wire to a client, if the same object can't be described as XML or JSON in a simple way for other clients requesting that. And there is no point in requesting ticket data and returning some complex type that clients like Mylyn can't ever be expected to make sense of.

That is why the wrapper/type system in use by Agilo should learn how to quack like ducks... A wrapper around a string by subclassing str and adding some __new__() magic, or whatever other way would allow it to behave like the underlying type.

I haven't looked at Agilo code, nor have I any plans to do so. Most of my arguments are of course highly speculative when I don't know what they actually do or why they do it...