Michael, when you say...
"It is similar to IObservableModel [3] but it seems to be more complete"
I can't help but think of Mike M's comments about simplicity trumping
capability in the AJAX community (I guess I'm a closet AJAX guy...;-). We're
going to have to 'sell' what we come up with to the community at large or we
fail. At best this is going to mean successfully conveying a substantial
paradigm shift (to modeling). IMO, anything showing up that's not currently
needed will just make the story harder to sell...
Of course that's not to say that having the capabilities is bad just that we
should only expose what's necessary to handle the work-flows we expect in
e4's -first- release...
Each part of API 1.0 should have a clear and current -need- to be there,
backed by a work-flow that documents its necessity ('we might need this' is
not a work-flow...;-).
Form follows function; Instead of asking 'What does it look like?' maybe we
should be asking 'What do we need and why'. As long as the resulting API
(including every argument of every method) is not only capable of but
-necessary to- supporting these requirements everything else is semantics,
necessary but relatively unimportant.
As we proceed it'll surely grow but that growth will be driven by an
identified need (as it is currently in our current API's).
Onwards,
Eric
_______________________________________________
eclipse-incubator-e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
