[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipse.org-architecture-council] Proposal API/extension point design workshop
|
I'd like to see this discussion go beyond the details of API in Eclipse
(though this is certainly necessary to discuss as well) to also include
general framework creation questions. API aside, what makes a good
framework? While the API are an important window into a framework, I've
personally seen a number of examples where over-concentration on API
definitions yields a façade on questionable code base (or, more colorfully
"lipstick on a pig"). Two books have helped me in thinking about these
issues in the past:
"Framework Process Patterns" by Carey and Carlson
"Framework Design Guidelines" by Cwalina and Abrams
The first is very interesting since it talks about the process of defining
frameworks, not just the output (frameworks/API themselves). The second is
mainly for Microsoft developers (gasp!), but has a lot of ideas that can be
broadly applied to framework design.
Regards,
John Graham
Eclipse Data Tools Platform PMC Chair
Staff Software Engineer, Sybase, Inc.
http://dataplat.blogspot.com/
David M Williams
<david_williams@u
s.ibm.com> To
Sent by: "eclipse.org-architecture-council"
eclipse.org-archi <eclipse.org-architecture-council@e
tecture-council-b clipse.org>
ounces@xxxxxxxxxx cc
g
Subject
Re:
05/11/2007 09:21 [eclipse.org-architecture-council]
AM Proposal API/extension point
design workshop
Please respond to
"eclipse.org-arch
itecture-council"
<eclipse.org-arch
itecture-council@
eclipse.org>
Just to raise some more ideas ...
Depending on the final scope, purpose, and interest ....
It might be useful to include or even focus on an "API Tools" aspect to
such a summit, or workshop.
You know, 'Discouraged access warnings' are a good start ... what's next?
And ... our favorite ... who's interested in writing them :)
Be sure to include Anti-API ...
what's bad API look like
how/when do API become "hidden" (compiles ok,
but leads to subtle, hard to spot dependancies on certain
behavior, right or wrong, that might lead to large re-writes later.
besides Java and extension points, what can be said about other languages?
C++, Javascript, taglibraries, webservices, or even file formats?
Still within or how-pertains to Eclipse of course :)
I think the final goals and deliverables should be something more concrete
and tangible.
Even if the very final form of the deliverable goes beyond the workshop,
the workshop
could have a goal of a first draft, of ...
- a book on Eclipse APIs (don't know if it's still done, but there used
to be books where
an editor would collect and organize "chapters", each written by a
different person, therefore
more loosely organized than usual, but still organized. [Handbook
of Human-Computer
Interaction, Ed. Martin Helander is one example of what I mean, if
that helps.]
- a tool to do xyz?
- an architecture or data format that allows API tools to interoperate,
or exchange data?
Good idea Michael ... may be lots of interest ... now, if we could plan to
hold the summit on one of those cruise ships ... :)
"Scharf, Michael"
<Michael.Scharf@xxxxxxxxxxxxx>
Sent by: To
eclipse.org-architecture-council-bo <eclipse.org-architecture
unces@xxxxxxxxxxx -council@xxxxxxxxxxx>
cc
"Scharf, Michael"
05/11/2007 12:27 AM <Michael.Scharf@windriver
.com>
Subject
Please respond to [eclipse.org-architecture
"eclipse.org-architecture-council" -council] Proposal
<eclipse.org-architecture-council@ API/extension point
eclipse.org> design workshop
Hi,
since we don't have regular architecture council meetings anymore
and we have decided to have workshops on special interesting topics,
I'd like to propose a workshop on API and extension-point design.
<when I say API this also includes the design of extension points>
What are the goals?
-------------------
- Exchange experiences with defining API
- Build up a tribal knowledge on APIs
- Learn from bad APIs
- Learn from successful APIs
- Sharpen your eye for good and bad APIs
- How make design extensible for the future (don't
make your decisions today block you tomorrow)
- Get help on your current work on APIs
- ... what ever you want to share/learn about APIs
and extension points
Who should come to the workshop?
--------------------------------
- Anybody involved in API design
How to prepare?
----------------
- Every participant has to submit a paper/slide deck
- Come with some API you want to have reviewed or
where you need help.
- Bring some API you are proud of.
- Bring some API you struggle with.
- Bring examples of the evolution of your API.
What will we do?
----------------
- everybody/some will present the submitted paper
(depending on the number of participants)
- we will split into small workgroups
- focus on one participants API/problem
- discuss it, dig into it (hands on!)
- iterate until each member has been in the
focus
What do you think?
Feel free to change the agenda, goals etc.
This is just a first raw proposal!
Michael
--
Michael Scharf, Wind River
direct +49.6621.586.0139 mobile +49.173.664.2579 fax +49.6221.436.805
_______________________________________________
eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-council
_______________________________________________
eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-council
