On attachments, the solution should perhaps anticipate a given
attachment might be referenced by more than one page (avoiding
multiple
copies). Moreover, there might be a good reason for simply
referencing
an attachment (if the attachment is huge) rather than storing a
separate
"attachment" object.
Well, attachments *can* be referenced by multiple pages already. It
is also unlikely that the exact same copy of the attachment would be
uploaded to multiple pages at the same time...
On author ids, I assume you mean user ids? If so, I don't see how you
could avoid storing the id on the backend, since the id is the unique
identifier, not the name.
Well, we could do exactly what we're doing now: store the WikiName of
the editor. This has the advantage of being human-readable
throughout the time, and easily exportable.
What is the "repo model?"
Repository model. The agreement that JSPWiki will use. The current
thinking is to use a workspace called "jspwiki", with the following
structure:
/wikispace/pagename[/subpage]*[/attachment]
For example:
/mainspace/Main
/mainspace/TextFormattingRules
/mainspace/TextFormattingRules/TableEditing
/mainspace/TextFormattingRules/sample.png
/Terry's Space/Main
/Terry's Space/Some page
Each Node (all these are called Nodes) contains a Property,
wiki:contentType, which determines what kind of an object this is.
If it is "text/x-wiki.jspwiki", we interpret it as JSPWiki Markup.
That is, all old wikipages would be included as this type. We can
also in the future put in other types, like "text/x-wiki.creole" to
support Creole natively. Any of these page types can be attached to
a Renderer object (which, for jspwiki markup objects would of course
be the JSPWikiMarkupParser + XHTMLRenderer).
This is pretty powerful.
The repository implementation then stores this in any way it wants.
I'm hoping that I can write a JSPWikiVersioningFileprovider for
Priha, which would then allow us to use the current
VersioningFileProvider stores without (massive) modification.
/Janne
