I'm very glad I decided to start with a simple survey. Firstly, I got
many more responses than I expected which certainly helps increase
energy and enthusiasm. More importantly, the results very much help to
make clear what the next directions for membrane/remember should be.
I've aggregated the responses into a Google Docs spreadsheet:
http://spreadsheets.google.com/pub?key=pOHTxcNSd5heSsdiwTa0DFA
If any more responses come in, I'll be updating the spreadsheet as they
do, so you can keep checking back there should you want to.
There were 15 respondents representing 32 membrane and/or remember
deployments. There was very consistent agreement on both the general
and specific development directions.
For general development directions, simplicity and maintainability is
the clear first priority, quite a bit ahead of everything else.
Performance and new features are likewise the clear second and third
priorities.
When it comes to specific development directions, lightweight AT profile
schema was the clear first priority, far ahead of the non-AT option.
The interesting bit here is that a non-AT option has been the focus of
much of the discussion on the plone lists has been the clear first
interest from those close to Plone core development and Rob himself.
One of my assumptions about membrane/remember usage in the wild was that
it was often used just for extending the profile with AT schemata
without making use of any other content behavior. It's been my
impression that membrane/remember is too heavy and invasive to use for
just this. The survey results indicate, however, that membrane/remember
are used most often for both AT profile schema *and* membership
workflow. Very good to know.
Finally, only about a third of the respondents or use membrane without
remember. This is pretty much as I expected. As maintainer, I'm taking
this as a reminder that purity in membrane is all well and good, but
that the health of or progress remember should not be sacrificed.
The rightmost half of the columns in the spreadsheet contain the same
response values but weighted by the number of deployments. One of my
concerns as maintainer was that there might be a divergence of
priorities between those who are responsible for just their own
deployment and those, such as consultants, who are responsible for
multiple deployments on behalf of others. Such a divergence could have
made it difficult to keep everyone happy. The results, however, show no
divergence. Those who are responsible for many deployments have the
same priorities as those with just one.
The percentages listed above the weighted totals show how much the
weighted value changed compared to the unweighted values. It thought it
might help identify any divergence. I'm not sure how significant these
numbers can be, but it seems that membrane only usage and performance as
a first priority for general development may be significantly more
important to those who are responsible for more deployments than those
who are responsible for less. Not terribly surprising and I don't think
it changes much, but it's worth noting.
Simplicity and Maintainability
==============================
As a maintainer, it's great to have such a strong mandate to focus on
simplicity and maintainability. It's nice to have a break from the
tyranny of new features. :) Both Rob and I have a lot of ideas for
where to start improving the simplicity and maintainability of membrane
and remember.
Workflow category mappers
-------------------------
Rob suggested, and I agree, that the workflow category mapper
infrastructure is overly complicated to no good end. In the interests
of simplicity and maintainability, I'll be adding deprecation warnings
before the next releases to give fair warning, and then I'll be removing
this functionality in some future release.
object_implements index
-----------------------
The object_implements index in membrane is too complex and a performance
problem. Rob suggested, and I agree, that we should simplify the index.
Currently, it indexes not only the interfaces provided by the object but
also any interfaces that the object can be *adapted* to down to second
order (two objects) adaptations. The problem lies in finding out what
interfaces an object can be adapted to.
Rob suggested that we use the marker interface pattern instead. IOW,
when an adapter to one of the relevant interfaces, IFoo for example, is
implemented, objects that it can adapt should be marked with another
interface indicating it can be adapted, IPossibleFoo for example. The
index would then be queried on IPossibleFoo. One problem with this
approach is that it doubles the number of interfaces that can be queried
on. In membrane this would be from 9 to 18 interfaces. In the future,
we may try to pare down the number of distinct interfaces that membrane
queries for and then move to this marker interface pattern when it won't
result in such interface proliferation.
I also suggested, and Rob agrees, that we not index all interfaces
provided by an object, but instead use the ZCA to register the
interfaces we care about and index only those interfaces. This will
further improve index performance and reduce index size.
I'll start by adding a deprecation warning on import of the index
function indicating the change in usage pattern before the next
release. Then I'll implement the interface discrimination in the index
but still support indexing those interfaces an object can be adapted to
as a fall back with a more aggressive deprecation warning. Finally,
we'll deprecate indexing interfaces an object can be adapted to all
together in favor of the marker interface pattern.
AT in membrane
--------------
I'm not sure how soon I'll be able to put into removing the AT
assumptions from membrane, but doing so would increase simplicity and
maintainability. As such, I'll add deprecation warnings at the location
of all AT assumptions in membrane before the next release. Then if I
find the time I can start working on removing those assumptions for some
future release.
Non-AT Option
=============
The survey indicates that the non-AT option is less important but the
developer discussions on other lists indicates the opposite. Since
developers are more likely to write code that can be successfully
incorporated into membrane/remember, I'm guessing I'll focus my efforts
on watching the discussions and supporting any efforts that get started.
One thing we can do since simplicity and maintainability are the first
priority, is to prioritize moving the AT assumptions from membrane to
remember. This will make membrane, at least, simpler and more
maintainable and will better support a non-AT option.
Lightweight AT profile schema
=============================
It is, however, a bit hard to reconcile the agreement on lightweight AT
profile schema as the first specific development priority with the
finding and most are using membrane/remember for both AT profile schema
*and* workflow. This may be due to the intentional ambiguity in the
phrase "lightweight AT profile schema". So lets take this as the
opportunity to start that discussion. What does lightweight AT profile
schema mean to you?
To me it means essentially what ore.member aims to provide except with
AT schemata instead of zope 3 schema. Personally, I use zope 3 schema
and avoid AT whenever possible, but AT is still one of the most valuable
frameworks provided by Plone in terms of accessibility to integrators
and accidental technologists. Since AT schemata must be bound to
content, lightweight AT profile schemata would still mean that the
profile must correspond to a content object somewhere, unlike
ore.member. IOW, I want to explore if there's any gain in supporting
the use of AT schemata for member profile properties with integrated
form generation for the registration and profile edit forms *without*
any further integration into the PAS/membership APIs (such as
workflow).
When all things are considered, there may not be much value to be gained
from such an effort. But I've always wanted to be able to recommend
something more lightweight than the entire membrane/remember stack just
to make profile extension accessible to integrators familiar with AT.
Conclusions
===========
The amount of time I can put into work on membrane and remember is very
limited. As such, how much can be done and how quickly will largely
depend on where that limited time ends up going. While code talks, in
this case I think support time talks more. Specifically, the most
valuable contributions will probably be in the form of answering mailing
list questions so I can focus on development instead.
Of course, code *does* talk. So if the survey results mean what is
important to you isn't likely to rise to the top of the development
list, then by all means, start a branch. First, however, discuss on the
list your particular itch and your plan to scratch it. If you can
incorporate and reconcile the input and feedback of others, myself and
Rob among them, then such code, if well written and tested, may well be
incorporated into membrane and/or remember ahead of the priorities
established by the survey.
This month is a little hard for me, but next month I'll be preparing the
next releases of membrane and remember after putting all the appropriate
deprecation warnings in place. In the meantime, lets try to get all the
necessary discussions going!
Ross
--
Archive:
http://www.openplans.org/projects/remember/lists/remember/archive/2008/12/1228872795802
To unsubscribe send an email with subject "unsubscribe" to [EMAIL PROTECTED]
Please contact [EMAIL PROTECTED] for questions.
