| RE: [higgins-dev] Proposed change to IdAS |
|
I don’t
think so. Folks, especially Tony, at the F2F were saying that they felt that
requiring java 5 would limit the reach of Higgins. Presuming this is true, I
figured that since most of the code is in the plugins, this wasn’t a high
price to pay for eliminating a barrier. -Paul From:
higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of Jim Sermersheim Is there a reason
for this, other than "some people might not want to upgrade from
1.4.2"? Jim, A minor point.
In the interest of broader Higgins acceptance, at the last F2F we reversed our
position on the baseline JVM version. We've decided that for the core of
Higgins (though not strictly for plugins like context providers, etc.) we are
going to go back to version 1.4.2 and not require 5.0. -Paul From:
higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of Jim Sermersheim Ok, I checked in
a new IContext with overloaded getSubject and getSubjects methods for now. Here's what I was
thinking in terms of a simple, forward-compatible extensibility hook: To all methods,
add an (optional) argument of type Iterable<IExtensible>, where
IExtensible has: URI
getExtensionType(); boolean
isCritical(); Object
getExtensionData(); The type would
uniquely identify the type and semantics of the extension. The Object would
be whatever is needed for that functionality (in some cases, no object is
needed). The boolean
causes the method to fail if the CP does not support that extension if
true. If false, the CP processes the extension if it supports it,
otherwise it ignores it. Your new method
essentially does a merge and lets you specify which cuid to keep? Sounds
reasonable to me -- we can't do that atomically with the LDAP CP, but it seems
like a nice feature for CPs that can. Hey, there's an
idea for an extension called the "allow non-atomicity" extension --
it's presence allows a CP to execute the method even if it can't guarantee
atomicity. Jim I think I'd do
the easy thing for now and just add the method. [We can work on adding a method
extension mechanism later. We should take advantage of the fact that we can
still for a time make code-breaking API changes.] BTW, speaking of
IdAS methods to add. I've been wondering if we need a "merge one DS (well,
all of it's attributes other than its CUID attribute) into another DS and
delete the first DS" method. It's just a convenience method. And it would
be atomic as all IdAS methods are. -Paul From: higgins-dev-bounces@xxxxxxxxxxx
[mailto:higgins-dev-bounces@xxxxxxxxxxx] On
Behalf Of Jim Sermersheim I guess the other
consideration would be which methods to add this kind of thing to, and also
whether this kind of thing should be part of a larger "extension"
type. By the latter, envision some kind of extensible object that could
be passed to various methods such that CPs could support (or not) various
method extensions. The hopes would be to a) prevent the method signatures
from changing over and over as we add new capabilities, and b) allow anyone to
define their own new capabilities. This is the kind
of thing that will take a bit of thought, so I'd like to know whether people
think it's worth it before I plow ahead. Jim |