Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "IdAS API Extensibility"

Line 5: Line 5:
 
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.
 
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===
+
{{IdasExtensibilityProposal
 +
|prop=Add just one more argument
 +
|propdesc=
 
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.
 
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.
 
+
|idasimpl=
====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.
 
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.
 
+
|cpimpact=
* Pros
+
* Option B (which is preferred from the IdAS consumer point of view) causes the cp writer to implement twice as many methods.
** Easy and intuitive for the IdAS consumer.
+
** There are already nearly 100 methods to deal with
* Cons
+
* Adds another arg to everything
** Clutters up the existing methods (there are already nearly 100 methods to deal with)
+
* IdAS maintainer must remember to always ensure there is an extension param for newly added methods
*** Option B doubles the number of methods to be implemented by CP writers
+
|consumerexp=
** IdAS maintainer must remember to always ensure there is an extension param for newly added methods
+
Option (B) is very easy and intuitive for the IdAS consumer.
 
+
====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:
 
If option B is chosen (which is preferred from the consumer's POV, A consumer who might call a method like:
 
<pre>
 
<pre>
Line 31: Line 27:
 
myContext.getSubject("frank", extensions);
 
myContext.getSubject("frank", extensions);
 
</pre>
 
</pre>
 +
}}
  
===Use callbacks===
+
{{IdasExtensibilityProposal
 +
|prop=
 +
Use callbacks
 +
|propdesc=
 
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.
 
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.
 +
|idasimpl=
 +
<idas description here>
 +
|cpimpact=
 +
<cp writer impact here>
 +
|consumerexp=
 +
<consumer experience here>
 +
}}
  
====IdAS implementation====
+
{{IdasExtensibilityProposal
<desc>
+
|prop=
 
+
<proposal here>
* Pros
+
|propdesc=
* Cons
+
<proposal description here>
 
+
|idasimpl=
====CP writer impact====
+
<idas description here>
<desc>
+
|cpimpact=
 
+
<cp writer impact here>
====IdAS consumer experisnce====
+
|consumerexp=
<desc>
+
<consumer experience here>
 
+
}}
{{IdasExtensibilityProposal|prop=proposal|propdesc=proposal description|idasimpl=idas description|cpimpact=cp writer impact|consumerexp=consumer experience|}}
+

Revision as of 15:31, 30 November 2007

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.

CP writer impact

  • Option B (which is preferred from the IdAS consumer point of view) causes the cp writer to implement twice as many methods.
    • There are already nearly 100 methods to deal with
  • Adds another arg to everything
  • IdAS maintainer must remember to always ensure there is an extension param for newly added methods

CP extender impact

{{{cpextender}}}

IdAS consumer experience

Option (B) is very easy and intuitive for the IdAS consumer. 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

<idas description here>

CP writer impact

<cp writer impact here>

CP extender impact

{{{cpextender}}}

IdAS consumer experience

<consumer experience here>

<proposal here>

<proposal description here>

IdAS implementation

<idas description here>

CP writer impact

<cp writer impact here>

CP extender impact

{{{cpextender}}}

IdAS consumer experience

<consumer experience here>

Back to the top