[annotator-dev] Annotator architecture evolution

Jamie M Folsom jfolsom at MIT.EDU
Wed Jul 10 15:34:08 UTC 2013

Hi Nick,

Thanks so much for the update, and for the glimpse at the roadmap. I have a question that may be relevant to this discussion.

Annotator is appealing not only for its functionality, but as a platform; the plugin architecture serves as a way coordinate development efforts (even divergent or competing efforts), and allows code sharing between implementations. As enthusiasm for the Annotator grows and as implementations proliferate in higher ed, I have been encouraging developers who are looking for ways to participate to consider writing plugins.

In that context and in light of the evolution you've outlined, I'd be curious if you or others think it would be worth revisiting the plugin packaging question that Randall raised here a while back: https://github.com/okfn/annotator/issues/117  Explicit configuration requirements/guidance and dependency declarations might be nice to have, for example. While I don't know if they're appropriate or useful, requirejs and browserify might serve as models or examples.

Currently it seems like plugin development competes for developer effort with both full-blown forks on the one hand and vanilla implementations on the other. If packaging and configuring plugins for different solutions were as standardized and frictionless as possible, plugin development might capture more of our collective effort, which would seem to be a Good Thing, since new plugins "raise all boats", rather than just one at a time.

Many thanks again for all your work.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1583 bytes
Desc: not available
URL: <http://lists.okfn.org/pipermail/annotator-dev/attachments/20130710/2a42193e/attachment-0004.bin>

More information about the annotator-dev mailing list