At 11:48 AM 10/12/2007 -0700, Davor Cubranic wrote:
On Wed, 10 Oct 2007, Phillip J. Eby wrote:
Note, too, that nothing that is being contemplated rules out the
possibility of having user-defined schema at a later date. Nothing
stops anyone from writing a plugin that contains a static schema that
meta-models dynamic schema elements, for example.
But plugins can still define their own data types, right?
Yep, just like now.
The limitation
is in types of attributes these data types can include and kinds of
relations between those attributes?
There will probably be a different set of standard data types,
yes. And the way you define the schema may change, such that the
schema is separate from the classes that have the schema, because in
the alternate architecture we want to move away from building
persistence into the objects themselves. (So that the persistence
system is decoupled.)
What I'm referring to is that end-user programmability of Chandler has
not been a primary goal of Chandler development for about two years
now, and there has been a moratorium on new investment in that
direction. Indeed, even platform improvement was designated as
secondary, with priority to be given only to platform issues affecting
the core PIM application development.
Do you by this mean third-party plugins? That they're possible, but not
actively encouraged by OSAF or work put into changing the platform APIs
to make writing those plugins easier?
Right. Core application functionality is generally favored over
platform improvements that would improve the
pluggability/extensibility of the application. In places where we
were doing work anyway, we've felt pretty free to add new hooks (e.g.
startup/task framework, quick entry system, dump/reload, etc.), but
we haven't generally been refactoring any existing areas *solely* to
improve the plugin developer experience.
If we implement the architecture prototype that Grant and I have just
about finished a first-pass design on, it will offer major leaps
ahead in pluggability in a number of areas, although that's more of a
side effect of the "fair play" rule than because we're specifically
trying to improve on it as such.
That is, in the revised architecture, *everything* is a plug-in in
some sense, so there would be no real difference between the Chandler
core app functionality, and the functionality provided by
plugins. For example, you could create an extension that implements
your own custom recurrence rule mechanism, or a that creates a new
kind of filter/view for the summary area, where those things aren't
separable in the current system.
For lots of features in Chandler today, we have that sort of level
playing field already, but there are still many places where we're
more monolithic and/or circular than is desirable even for our own
development purposes, let alone third parties.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
