Signet Working Group conference call
October 13, 2006
*Attendees*
Lynn McRae, Stanford U. (chair)
Dave Donnelly, Stanford U.
Gary Brown, U. Bristol
Tom Barton, U. Chicago
Monica Crawford, U. Wisconsin
R.L. “Bob“ Morgan, U. Washington
Steve Olshansky, Internet2
Jessica Bibbee, Internet2 (scribe)
Carry Over *Action Items*
[AI] {Lynn} volunteered to relocate items to the I2MI-Common, such as loading tools, etc. (9-Sep-06)
[AI] {Dave} will update the requirements text to reflect the upgrade to Java 1.5. (18-Aug-06)
[AI] {Tom} will email the grouper- and signet-user mailing lists to probe for issues related to versioning changes. (18-Aug-06)
[AI] {Tom} will email the list with potential contacts at Macquarie University. (18-Aug-06)
[AI] {Lynn} will request use cases and other agenda topics for the CAMP program. (21-Jul-06)
[AI] Contact {Lynn} if you identify additional functional requirements for your local project. (28-Apr)
[AI] {Bob} will send .htaccess local syntax to the group via the list.
[AI] {Group} will develop use cases for Signet.
[AI] {Minh} will develop a list of requirements for how Signet will interface with LDAP and Grouper.
[AI] {Lynn} will write up a person and function summary to express the relationship of privileges to roles and to determine what gets expressed in the eduPerson entitlement space.
*Agenda*
1. Events reminders: November Signet/Grouper CAMP; December I2 Member Meeting.
2. Packaging (cf. email 13-Oct)
*Discussion*
{Lynn} discussed the housing of items, not just as a CVS storage, but also as the package structure. Which items should be positioned in the Subject repository or in the I2MI-Common area? Older items will be superseded by newer work, and there ought to be a pattern for housing code.
Software can be extended in several ways: 1) the core developers add a substantial piece, worthy of calling it an extension, 2) a user contributes a component that is then blessed and either adds to or replaces a component in the existing software. The Group still had questions over what is/will be considered an official extension versus a simple plugin. A few of the anticipated items are additional skins, as well as alternate configurations and language localizations.
{Dave} believes that the requirements should drive how a core addition vs. plugin is put into CVS, how it is deployed, etc. What are the core requirements of a product, and how useful is it? Will it just be made available or will it be distributed with the main product? Is it blessed by the developers and will it continue as an integral piece of the product? Some may be promoted to replace core components, while others will be promoted to simply enhance the product. He anticipates valuable contributions from the user community, and each will undergo a review process.
The official sanctioned build should only deal with that which is considered core; plugins should have a separate build, which is the responsibility of the contributor to provide.
The requirements for moving a contribution into the Internet2 CVS are quite high. The Group decided that the final destination/integration of each contribution is best decided on a case-by-case situation. There may be an instance when a contributor is welcomed as a code ‘committer’, but generally the core developers will make these decisions.
Licensing of contributed components is another issue that should be discussed in full. Listing everything in CVS under the same license will clear any confusion about which license(s) covers core items. Additionally, it was mentioned that an addition of or change to any component within the core product necessitates a change to the product version as a whole.
Another element of packaging is, of the blessed items, which should be included as default and which should be made available on the side. In this way, people can choose to download exactly and only the components that they chose, as opposed to the entire lot of blessed items. For example, the KITN population could become a separate download only for those wanting a practice database of subjects. For other items, it may be possible to include more than one option, without the difference impacting user experience.
A provisioning connector is anticipated in time for the upcoming CAMP: Building a Distributed Access Management Infrastructure, November 7-9, Denver. <http://www.educause.edu/content.asp?SECTION_ID=226>.
Additional face-to-face discussions will continue at the nearing Fall Internet2 Member Meeting, December 4-7, Chicago. <http://events.internet2.edu/2006/fall-mm/>.
The next Signet WG call will be on Friday, October 27, 2006 at 11am EDT.
**Subject: Signet call, thoughts on subject sub-packaging** (cf. Lynn’s email 13-Oct-06)
Some organized thoughts for our Signet discussion this Friday. I'll start with Subject.
Currently the Subject hierarchy adds a "provider" directory embedded in a few spots:
===================================================
subject
build
edu/internet2/middleware/subject/
==> provider
==> BaseSourceAdapter.class
==> JDBCSourceAdapter.class
==> JDBCSubject.class
==> SourceManager.class
==> SubjectTypeEnum.class
Source.class
SourceUnavailableException.class
Subject.class
SubjectNotFoundException.class
SubjectType.class
build.xml
conf
log4j.properties
sources.xml
cpappend.bat
dist
doc
lib
i2mi-common-0.1.0.jar
README.txt
==> ? stax-api-1.0.jar
==> ? wstx.jar
LICENSE.txt
NEWS.txt
README.txt
src
edu/internet2/middleware/subject/
==> provider
==> BaseSourceAdapter.java
==> JDBCSourceAdapter.java
==> JDBCSubject.java
==> JNDISourceAdapter.java
==> JNDISubject.java
==> NullSourceAdapter.java
==> Search.java
==> SourceManager.java
==> SubjectTypeEnum.java
Source.java
SourceUnavailableException.java
Subject.java
SubjectNotFoundException.java
SubjectNotUniqueException.java
SubjectType.java
test.bat
test.sh
tests
===================================================
I think this brings up a number of obvious points:
(1) We know what the JDBC and JNDI things are, and might assume by
common name stem that the XXXXSourceAdaptor.java and XXXXSubject.java
belong together. But what of BaseSourceAdaptor, NullSourchAdapter,
Search, SourceManager and SubjectTypeEnum? Who do they belong to?
What do they do? are they offerings of their own or parts of something
else? Even within one subdirectory, the intermingling of parts of
multiple contributiosn in untenable.
(2) Other directories
-- what if a contribution had a unique external jar requirement?
Though it's not reflected above, this pattern suggests a lib/provider directory with an undifferentiated set of jars and unclear ownership. Or are the two marked jars, not mentioned in the README, in fact there because of provider stuff?
-- What if two add-ons had their own configuration? All of them together in conf/provider? Imposed unique naming requirements?
(3) Still other directories, ones that Subject doesn't even need. Should the Subject hierarchy have a "schema" or "data" directory just to host a provider sub-directory, when they aren't relevant to the Subject api?
What I am leading to is the thought that the primary package, e.g., Subject, stay pure and dedicated to the core code itself, that each "contribution" be in a single "provider" directory (better name?) to house named sub-packages. Each sub-package is then free to carve out their sub-space in any way that suits them, something like:
===================================================
subject
build
build.xml
conf
log4j.properties
sources.xml
cpappend.bat
dist
doc
lib
i2mi-common-0.1.0.jar
README.txt
LICENSE.txt
NEWS.txt
---------------------------------
provider
JDBCAdapter
build
build.xml
conf
adapter.xml
doc
lib
i2mi-common-0.1.0.jar
stax-api-1.0.jar
LICENSE.txt
README.txt
src/edu/internet2/middleware/subject/
provider
BaseSourceAdapter.java
JDBCSourceAdapter.java
JDBCSubject.java
Search.java
SourceManager.java
SubjectTypeEnum.java
JNDIAdapter
build
build.xml
conf
adapter.xml
doc
lib
wstx.jar
LICENSE.txt
README.txt
src/edu/internet2/middleware/subject/
provider
JNDISourceAdapter.java
JNDISubject.java
Search.java
SourceManager.java
SignetLightWeightSubjectRepository
build
build.xml
conf
data
kitn-subjects.xml
sample-groups.xml
doc
lib
stax-api-1.0.jar
README.txt
schema
ddl
hsql
oracle
postgres
src/edu/internet2/middleware/subject/
provider
Subject.java
util
SubjectXmlLoader ...
---------------------------------
README.txt
src/edu/internet2/middleware/subject/
Source.java
SourceUnavailableException.java
Subject.java
SubjectNotFoundException.java
SubjectNotUniqueException.java
SubjectType.java
test.bat
test.sh
tests
===================================================
There might be more trappings to these -- certainly they benefit from separate readme's. Maybe they could be grouped by the kind of thing they are -- adapters, provisioners, ???. That could be an excess here but we'd want some rational organization of such things when we presented them for optional download. Each sub-package should get a separate compile, be offered for independent download? Would still be considered a src/edu/internet2/middleware/subject/provider package? Would buy-in to i2mi-commons be a prerequisite for this space?
I'l also treating these are a several of many, in a list that could grow, but I don't have clear in my mind what sorts of things get dropped off in a "third party, as-is, sample" shared code spot vs what makes it as far as getting into the Subject package CVS per above. We could have a couple of competing JDBC or JNDI source adapters over time for instance.
Finally, whatever principles we work on for this should apply to the Signet packages as well. We have tiles as part of the primary UI provided by the project; how are other tiles contributed, managed if they are not "core". We could have alternate conf files, e.g., for language localizations. Interestingly, with the subject stuff moved out Signet doesn’t have much today for the "contributions" space, but I'm sure it will come.
Lynn