Talk:Mahara Portfolio Plugin

Question 1

It occurs to me that maybe Mahara could send back information about where files could be put/blogposts could be stored etc, as part of the reply to the "intent to send" request? In the "happy path", we wouldn't expect this information to change, so maybe it's safe to send back something then? Nigel McNie 07:40, 20 July 2008 (CDT)

We'd have to send back information about where to put any possible content though, because at the intent to send stage, we don't know what format it is (eg, it might just be a file but could be a LEAP/PIOP component, which would go into a whole another artefact plugin). we'd essentially have to send back the entire artefact tree. and then even if we did that, at that point Moodle still doesn't know what format the user wants, so we'd still have to add another step._ Penny Leach

Proposed MNET Changes

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)