Re: [eclipse.org-architecture-council] Discovery and Reuse Activity Upda

[Valentina Popescu <popescu@xxxxxxxxxx>]

Oisin, 

Having the catalog initially populated
with components that owners have decided to expose as reusable components
( through API ) is a good first step. I am looking forward to the wiki
page you are planning to put together :) I also think that this work, if
successful, will result in better usability across projects since it will
eventually remove duplicate functionality

I would like to see a section on the
wiki page for components which are proposed to be made reusable by other
than the owners of the function. This should cover cases where a function
is not necessarily seen as a reusable candidate by the component owner
because he is not aware of any usage other than his own. 

Concrete example: One project offers
validation for xml instances. Another project wants to provide a similar
validation functionality for a new xml spec. There is a need for a common
component and extendable validation framework both for reuse ( avoid re-inventing
) but also for usability reasons. The last thing a user wants to do is
to figure out which one of the two Validate actions on an xml file is the
one he really wants to use.

Thank you,
Valentina Popescu
Senior Advisory Analyst
IBM Toronto Labs
Phone:  (905)413-2412         (tie-line  969)
Fax: (905) 413-4850

Oisin Hurley <ohurley@xxxxxxxx>
Sent by: eclipse.org-architecture-council-bounces@xxxxxxxxxxx

11/09/2006 05:10 AM

Please respond to
"eclipse.org-architecture-council" <eclipse.org-architecture-council@xxxxxxxxxxx>

To	eclipse.org-architecture-council@xxxxxxxxxxx
cc
Subject	[eclipse.org-architecture-council] Discovery and Reuse Activity        Update

Hi all,
As you all no doubt lucidly recall, myself and John Graham
volunteered at the meeting in Stuttgart to make some progress
on the issue of re-use of functional elements within disparate
eclipse projects.

The purpose behind this venture is, in my mind, to help boost
the growth of the ecosystem by facilitating the discovery of
functionality within projects, which should in turn lead to
a greater potential for re-use and less chance of duplicative
work. Eclipse is a big place, and it can be very difficult to
find things out at this level :)

I must give my regrets for attendance at the Arch Concall, as
I am currently travelling in China and the call takes place
in the middle of the night in my timezone.

John and myself have been discussing the parameters of the
activity off-line, as a prelude to putting information on the
wiki. I had planned to put up the wiki page today, but I'm
having some minor logistical issues and the jet lag is starting
to bite, so I am emailing it instead. Your comments will be
incorporated into a wiki entry as soon as I can get over the
wiki access issues.

---

Our proposal is that the initiative should commence with the
population of a 'catalog' of functional elements that can be
search on function and project. This will aid in the discovery
process when an existing or proposed project wishes to first
confirm that a function is not already catered for within the
bounds of the existing ecosystem.

The catalog should be based on components with an API since
these are the parts that a project has chosen to expose to
the world, by the act of defining and support an API for them.
However, it would be useful to have some kind of dim vision into
internal (non-public-API) functionality too, so that people
could re-purpose rather than re-invent. The catalog could clearly
indicate whether a component is API supported or not. Then, it would be
up to potential consumers to either
    (1) work with the providing project to get an API defined
or
    (2) take a chance and use an internal component.

Of course, within projects there will be some variations, so
perhaps some projects enforce API boundaries within the project
itself and some do not. This might become an issue, and could
be an item upon which the Architecture Council might see fit
to issue a guideline (Ask the Architecture Council...)

The next act is to put a wiki page up (or a web page off Arch
Council page? what is best?) with the details of the effort,
and calling for contributions. Then we can fill in the details
from the projects on an ongoing basis.

Comments?

  regards
   Oisin
_______________________________________________
eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-council