Skip to main content
Jump to: navigation, search

IdAS API Extensibility

Revision as of 14:15, 30 November 2007 by Jimse.novell.com (Talk | contribs) (New page: This https://bugs.eclipse.org/bugs/show_bug.cgi?id=196390 task asks for a way to "future-proof" IdAS interfaces by inventing some way that we can introduce new arguments and semantics ...)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

This [task] asks for a way to "future-proof" IdAS interfaces by inventing some way that we can introduce new arguments and semantics to existing interface methods without actually revising those methods or adding overloaded versions of them

The terms extension and extensions refer to the additional arguments which would be somehow conveyed to the method being called. An extension should consist of at least an identifier, and possibly some payload (data). The identifier is associated with (defines) both the semantics of an extension as well as with the payload.

Here, we list some possible ways of doing this, along with the impact each has on the cp-writer, and what the IdAS consumer's experience would look like. I believe we can talk about the proposed ways in which extensions are passed/associated with existing methods separately from defining the format of the extension. For now, we'll assume the format of the extensions is an Arg[]. Arg will be defined by us.

Add just one more argument

Add to each method in the IdAS interfaces (Java Interfaces in org.eclipse.higgins.idas.api) one optional argument which allows the caller to pass extensions.

IdAS implementation

For each IdAS method, either: A: add one argument (Args[] args) as the last param, where args may be null, or B: overload each method by adding this additional param.

  • Pros
    • Easy and intuitive for the IdAS consumer.
  • Cons
    • Clutters up the existing methods (there are already nearly 100 methods to deal with)
      • Option B doubles the number of methods to be implemented by CP writers
    • IdAS maintainer must remember to always ensure there is an extension param for newly added methods

CP writer impact

See the cons list. Option B (which is preferred from the IdAS consumer point of view) causes the cp writer to implement twice as many methods.

IdAS consumer experisnce

If option B is chosen (which is preferred from the consumer's POV, A consumer who might call a method like:

myContext.getSubject("frank");

would do this when calling the same method with an extension:

Args[] extensions = {<stuff>};
myContext.getSubject("frank", extensions);

Use callbacks

Allow the IdAS consumer to set up callbacks which will be called by the CP implementation of a method in order to gather extensions for that method.

IdAS implementation

<desc>

  • Pros
  • Cons

CP writer impact

<desc>

IdAS consumer experisnce

<desc>

<proposal>

<desc>

IdAS implementation

<desc>

  • Pros
  • Cons

CP writer impact

<desc>

IdAS consumer experisnce

<desc>

Back to the top