[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[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