proj-oot-ootComponent

Oot should make it easy to write software with a 'plug-in architecture', whatever that means.

---

component programming

broadcast events, listeners, hooks

look at android, eclipse, http://code.enthought.com/projects/envisage/, twisted, http://pypi.python.org/pypi/Plugins/0.5a1dev, http://home.gna.org/py-notify/ , zope; see also http://stackoverflow.com/questions/1092531/event-system-in-python , netbeans component architecture

basically we want a language where stuff like the above is almost effortless rather than requiring each framework to come up with its own ad-hoc way to talk about signatures and interfaces within the language. Perhaps first-class signatures and interfaces get you most of the way there. See comment on "API-definition language" in ootNetMatching.

also, this is somewhat different from the above, but look at Maven archetypes, example http://blogs.atlassian.com/2011/02/plugin_architecture_episode_iv/

---

Some ideas:

---

notes on Envisage:

five things: Interfaces, Extension points, 'Contributions to extension points', Services, Plugins.

An Interface is an opaque abstract identifier (i think?) that stands for a promise to obey a certain API.

An Extension point is basically a function signature; like a C header, it defines a callable (again, English language meaning) with a signature and a name.

A 'Contribution to an extension point' is a definition of the function declared in a particular Extension point.

A Service is an object factory paired with (a) a promise that the produced objects obey a particular Interface, (b) a set of key-value pairs representing attributes of the service (do these also represent default arguments to be passed to the factory?)

Plugins are just 'packages' (i don't mean Python packages, just the English concept of 'package') of extension points, contributions to extension points, and services.

Two actions (aside from declaring/creating the above): (a) bind extension point contribution to extension point, (b) lookup service (by interface, but can use more complex queries on the service attributes).

http://docs.enthought.com/envisage/envisage_core_documentation/index.html

http://docs.enthought.com/envisage/envisage_core_documentation/howto_create_a_plugin.html#what-does-your-plugin-do

---

http://stuartsierra.com/2011/08/30/design-philosophies-of-developer-tools

"

    Plan for integration
    Rigorously specify the boundaries and extension points of your system
    Do not depend on unspecified behavior

And a couple of ideas if you’re starting a new project from scratch:

    The filesystem is the universal integration point
    Fork/exec is the universal plugin architecture

"

" All of Git’s “modules” seem to depend on a few data structures, and higher-level (porcelain) freely mixes and matches lower-level APIs (plumbing) to provide complex functionality. "

" Clojure does have first-class functions, which are easier to compose than any plugin architecture. But Clojure functions don’t provide a way to isolate different environments, making them less appropriate for something like a build tool. "

---

--- misc links

https://groups.google.com/forum/#!topic/clojure/irCGydnCNdA

http://web.archive.org/web/20120401141034/http://thoughts.inphina.com/2011/09/15/building-a-plugin-based-architecture-in-scala/