| | 3 | * '''Refactoring''' |
| | 4 | * virtual Feature Type instances for nonbinary feature types |
| | 5 | * pro: Don't have to handle nonbinary features as a special case all over the frontend code |
| | 6 | * con: Breaks clean object<->RDF mapping. ft.getSubclasses() suddenly needs Item as parameter. Eventually has to consider Trust. Not straightforward to implement. |
| | 7 | * Syncer should implement and use !ModelListener |
| | 8 | * pro: less resource consumption, proper diff handling |
| | 9 | * needs lots of rewriting |
| | 10 | * One Model per Skipforward webapp (new). Many users per Skipforward webapp (done). |
| | 11 | * pro: Less resource consumption (memory/filetransfers) |
| | 12 | * con: Syncer needs to know with whom to sync. Not trivial (what if one user moves from SF server A to SF server B?). Privacy issues (FactsDb needs to check resources it accesses against namespaces that are supposed to be visible to the user - has to trust XMPP server). |
