Developer Area/Import//Export/Meeting 20081029
From Mahara Wiki
< Developer Area | Import//Export
The following are notes from a developer meeting on IRC, held from 2008/10/29 11:15AM GMT - 2008/10/29 12:50PM GMT. The meeting was held in #mahara-dev on freenode.
Attendees
Nigel McNie and Penny Leach
Agenda
- Who is co-ordinating the work, in particular the workplan response?
- General architecture of the work
Notes
Delegate job of co-ordinating to James @ ULCC. People who should be involved in talking about the response: dev@mahara, Niall and Lorna from Glasgow, James at ULCC. [Editor's note: who else might be interested to "listen in" on conversations?]
Import and Export are different problems. The codepath and APIs will be different, and there is not a 1 to 1 mapping between export format and import format. Therefore, we want two new plugin types for this: import/ and export/
We should probably develop at least two plugins for import and export, so that the APIs can be tested as thoroughly as possible - we don't want to tie the APIs to one particular format.
Each plugin should be responsible for handling different versions of the format it deals with - for example, we have a LEAP plugin that deals with LEAP2A, and any future LEAP version - as opposed to a LEAP2A plugin and separate plugin for a future version. [Editor's note: I recall seeing somewhere that the A in LEAP stood for Atom - does that mean LEAP could be expressed in other ways, and where is the boundary then? Do we have a LEAP plugin or a LEAPA plugin?]
Transport was brought up briefly, but we agreed to see where it fits in later.
We began walking through a use case of a user exporting data. The user will need to choose export format. Penny pointed out that users might not know what format they wanted, but instead might know what system they need the data _for_. We agreed both choosing a format and choosing a system would be valuable at different times.
This brought up the idea for a second export format (other than LEAP) - a static HTML representation of the portfolio. There is evidence that people would like this format, and it makes sense that a user could export their portfolio in some form they can easily read. Another point brought up at this time was that there was the potential for import and export plugins to share code, but this wasn't explored in any detail.
We went back to debating what implications choosing a system would have for what export system was produced. There is an issue of what format should be used given system X is chosen. Nigel floated the idea of this choosing the most 'compatible' format we know about for the other system, raising questions about how we know this information. Discussion ensued about how systems adding support would be able to provide this information in a pluggable fashion, but we didn't come to a nice solution and agreed to skip this problem for now.
We discussed granular export (i.e. exporting only some of a portfolio), but it was agreed that this wasn't strictly necessary for this iteration of import/export. This brought up the question of exporting friend data, settings and permissions. Friend data and settings is probably not important for this iteration of export (though it might be worth asking Simon about how you might export that in LEAP format). View permissions may well be important, but Penny suggested that we hold off for now to see if the problem can be solved later in conjunction with other vendors.
The issue of how performant export would be was brought up - it's quite possible that many user might want to export large portfolios at the same time, causing performance issues. Several ideas were discussed as to how this problem could be managed, largely involving some (admin configurable) settings plus estimation to work out when to kick export generation to cron time. We'll need to discuss this in more detail later.
Mechanics of export - because both artefacts and formats are pluggable, one is not going to be able to exist self-contained in its own directory. Given artefacts already are, this means that artefacts will gain new export/ and import/ directories. The formats should provide a way to export any artefact in a generic way. Each artefact type should export a list of formats it exports to also, regardless of whether it needs a custom implementation or not. This allows certain artefacts to say that the base class export is sufficient for their export.
There should probably be two classes involved for export - there's the base class + children for exporting individual artefacts, and then a manager class to tie it all together and produce the boilerplate around the outside.
Agreed to stop there and talk about import next time.
[Editor's note: Penny produced a couple of skeleton classes as a result of this discussion, they're still under discussion]