Talk:MNet Roadmap

I think the application2service table is a good idea (no more Mahara "course enrolments"!). But I don't like the idea that the URL field is in this table. Even though it varies by application, it doesn't apply to _every_ service, and therefore is redundant much of the time. Furthermore, if more services are added that need their own custom per-application fields, all of a sudden this table is getting very big with a lot of poorly related fields.

A different model that doesn't suffer the problem is this:

application2service

Field	Datatype	Comment
id	integer	sequence
applicationid	integer	fk to mnet_application
serviceid	integer	fk to mnet_service

application2service_sso

Field	Datatype	Comment
id	integer	sequence
a2sid	integer	fk to application2service(id)
url	char(255)

Nigel McNie 06:41, 22 July 2008 (CDT)

What Hubert Hates about MNet (part 1)

• (trivial) 28-day key expiry is too short, IMHO. My own preference would be something on the order of 1 year.
• (easy) Inconsistent fault codes: when MNet encounters an error, it throws an XMLRPC fault with a seemingly random fault code. Some fault codes are used for multiple types of errors, and some errors are represented by multiple possible fault codes.
• (hard) XML-SEC envelopes bloat XMLRPC messages by a lot. Personally, if I were to design MNet from scratch, I think I would either use HTTP headers, or multipart to send the signature and encryption key. Obviously, this would be a backward-incompatible protocol change, and we would need to support both protocols in new code. Someone will have to decide if this is worth the fuss. I'm not expecting this to be addressed any time soon, but I just wanted to throw this out there and see what other people think.

The "Split between xmlrpc functions offered and xmlrpc functions available" mentioned in Penny's changes is also something that I'd like to see fixed.

That's all I can think of for now. I'll add more when I remember more. --Hubert Chathi 22:23, 6 January 2010 (UTC)