On Jul 6, 2011, at 12:49 AM, Urs Frei wrote:
I'm not talking about a API that is not
straight forward. We're extending AMP on a application level. Not on a
model level. So we're not struggeling with the API. Instead we need to
understand the internal implementation.
Fair enough but please note that the distinction is not always so straightforward, see below. Thanks for the examples, that is very helpful. The reason that I wanted to get the formatting done is that it is actually impossible to tell what changes you have made because the git diff isn't very good at filtering out white space, etc..
Example:
As an ILifeCylcleListener you'll get
informed about the initialization of the model when executing it. When
asking the IModel, it doesn't respond the same state. As a developer, that
is not an obvious behavior. I would like to refactor that.
1. Hmm, that sounds like a bug, not a refactoring. That is, when an observer is sent the message ILifeCycleListener#observeInitialize , IObservationProvider#isInitialized() should return true.
a. If the issue is in Ascape -- which seems unlikely but not impossible -- then yes, we should fix it there.
b. If the issue is in the Escape -> Ascape adapter layer or the API then we should fix it there.
c. There is no need to change the API to fix it.
2. To your more general point, the AXF API is provisional. We can make any changes we want to it at this point, that's why we're at 0.9.0 and not 1.0.0! There may be all kinds of ways that it can be improved.
Another example:
A scape has a method called "notifyViews".
In fact, this not only notifies views. Instead it notifies all ScapeListeners
that are registered as observers. As a developer, that is not an obvious
behavior. I would like to refactor that.
1. Again, the Ascape API is not perfect. It is not always clear where the Listener and MVC patterns meet and this is a case where I felt that views subsumed ScapeListeners. I realize that it is confusing, which is why I didn't repeat it here. But it has been around for many years and people may be relying on that behavior.
2. I think your distinction between "model level" and "application level" is a bit artificial. In reality, this is a public API, so people should be able to expect the existing API to stay supported. At most, we should deprecate the method, not replace it.
3. From the Application developer POV we can live with it and fix it on the AXF side of things. That's why you'll notice that I no longer call
4. You've made a change to ScapeListener DefaultScapeListener:
} else if (scapeEvent.getID() == ScapeEvent.TICK) {
scapePaused(scapeEvent);
}
a) This is a functional change not a refactoring.
b) ***You've just broken every API user who implements the ScapeListener API.*** (Because you've created a new method that they won't necessarily have implemented.) That's really not good, given that the Ascape API is on version 5.6, people have been using it for twelve years and we're not even making a whole version change. At the very least it would have made sense to create an IScapeListener2 interface that people could optionally implement.
c) It doesn't make sense,
i) because Tick is not a notification that a model has gone into a paused state, it is a periodic notification that the model is *in* a pause state. Which means that you will receive that message about 10 times a second, which might not be efficient if you're updating UI based on it.
ii) The pause/resume cycle should not be a model view concern; it is a control concern. It is not a "lifecycle" event.*
d) I can imagine that there might be some very good reason for you to need this kind of behavior, probably because you want notification for pause events for the UI.
There is a reason that EngineControl and LifeCycleState are not symmetrical -- I did not simply forget to include Pause,Resume and Step in the latter. I actually put a good deal of thought into it and while it might be wrong, it is worth at least discussing. Model listeners shouldn't care whether the model is paused or not, they only care about changes to the model state. That's important in for example a distributed execution situation where if I definitely want to know about every change to a model's state, but I definitely don't want to know every time some local update happens in the control UI. The TICK thing was an inelegant way to handle things, and that's exactly why I separated them out this time around. Again, our AXF API is provisional. If you'd discuss it with me first instead of assuming that I was being a "fool", we would be able to figure out a good way to accomplish what you're trying to accomplish and fix it if it is broken. I realize that it is annoying to have to go through that given time zone differences but it's worth doing. I think what we need is an IEngineListener.
4. Please note initial commit comments.
Finally please let me note that this is the first time I have managed a global Open Source project. I'm sure that I'm messing some stuff up, I know you're frustrated with the limitations that we're under, and I very much appreciate the contributions your team is making. I am sure that any failure in communication is more on my side of things than anything else and I apologize for that. No matter the context, any team of programmers must start with a mutual respect for one another's abilities and contributions.
best,
Miles
Von:
Miles Parker <milesparker@xxxxxxxxx>
An:
AMP developer mailing
list <amp-dev@xxxxxxxxxxx>
Datum:
05.07.2011 19:26
Betreff:
Re: [amp-dev]
Antwort: Re: Antwort: Ascape core
Gesendet von:
amp-dev-bounces@xxxxxxxxxxx
OK, I'm not really sure how to take that. :( But people
in the ABM community have found these APIs to be quite straightforward.
It may be a methodological thing, I dunno but it might make sense to back
up a bit and figure out what it is that the framework is doing before trying
to work around it.
Yes, there are ***completely obvious*** refactorings to
make, if we wanted to build a new version of Ascape, but you're still missing
the point. ***Ascape is Legacy***.You need to remember also -- this is
a point I keep trying to make -- Escape is simply an exemplar for the AMP
platform. Precisely because I didn't want to -- and couldn't for IP reasons
-- simply migrate Ascape to AMP, there is an abstraction layer there. So
there is a lot of extra complexity that wouldn't otherwise need to be there.
That's why we have all of those wrappers and everything. It is simply a
way to make models written against the Ascape API work inside of the Eclipse
AMP system, and since the APIs are similar it actually makes things more
confusing.
On Jul 5, 2011, at 7:43 AM, Urs Frei wrote:
Yes indeed. That seems a little complicated.
Right now, we're spending hours and hours trying to understand the implementations
of Ascape and Escape...
To make things as easy as possible, better understandable, better testable
and easier extendable, there are quite a few code snipped we'd like to
refactor. Obviously, they include Ascape. We really need an easy and light
development process.
Just as Martin Fowler would quote...
Any fool can write code that a computer can understand. Good programmers
write code that humans can understand.
:-)
Von: Miles
Parker <milesparker@xxxxxxxxx>
An: AMP
developer mailing list <amp-dev@xxxxxxxxxxx>
Datum: 04.07.2011
19:46
Betreff: Re:
[amp-dev] Antwort: Ascape core
Gesendet von: amp-dev-bounces@xxxxxxxxxxx
It's complicated, as usual. But yes, you have to actually build the dependencies.
For the orbit stuff we now get that from Orbit P2, so we can get rid of
o.apache.a, o.apache.c.c, o.jdom and o.junit. We maintain o.e.e.java, which
is a different story, we have a bug fix out to fix that one to use the
Eclipse EMF repos instead. In any case, the bottom-line is that we cannot
deliver anything that wasn't actually physically built at Eclipse. So no
jars, sorry, but we can and do use Eclipse hosted plugins where available.
:)
On Jul 3, 2011, at 11:57 PM, Urs Frei wrote:
Okay. We'll try and reverse those changes. We'll probably have to make
a patch for Ascape.
If we're not supposed to change Ascape sources, why are they put into the
git repository as sources? Why not use a JAR file. That way it would be
clear that nothing can be changed without explanation.
Talking about dependecies...
org.apache.ant
org.apache.commons.collections
org.apache.commons.lang
org.eclipse.emf.java
org.jdom
org.junit
are all included as sources as well. I don't think we're supposed to make
changes in those projects. Why are they in the git repository? Couldn't
we get rid of them?
Von: Miles
Parker <milesparker@xxxxxxxxx>
An: AMP
developer mailing list <amp-dev@xxxxxxxxxxx>
Datum: 01.07.2011
20:18
Betreff: [amp-dev]
Ascape core
Gesendet von: amp-dev-bounces@xxxxxxxxxxx
Hi guys,
I noticed some changes to Ascape core in bug 350813.
If I neglected to make this clear, for IP
reasons *we cannot make changes to org.ascape.* We area llowed to
include them only as dependencies. If we make changes to ascape proper,
we need to apply them to the sourceforge code base (I'm happy to make you
committers on that as well) and then put them through a CQ to get them
back into AMP. I know, a complete PITA, but that might make it a little
clearer why I've avoided some obvious design improvements. Let's figure
out a set of changes and bundle them up. It's not like it's an incredibly
difficult process, but it does take at least a few days and often a week
or two to get them approved. For now, please back those changes out --
it's important that they don't end up in a released build.
thanks,
Miles
_______________________________________________
amp-dev mailing list
amp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/amp-dev
________________________________________________________________
Urs Frei, Ingenieur FH
Wissenschaftlicher Mitarbeiter
Fon +41 71 226 12 22
Fax +41 71 226 12 13
Web http://www.fhsg.ch
FHS St.Gallen, Hochschule für Angewandte Wissenschaften
IMS-FHS | Poststrasse 28 | Postfach 1664 | 9001 St.Gallen | Switzerland
FHO Fachhochschule Ostschweiz_______________________________________________
amp-dev mailing list
amp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/amp-dev
_______________________________________________
amp-dev mailing list
amp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/amp-dev
________________________________________________________________
Urs Frei, Ingenieur FH
Wissenschaftlicher Mitarbeiter
Fon +41 71 226 12 22
Fax +41 71 226 12 13
Web http://www.fhsg.ch
FHS St.Gallen, Hochschule für Angewandte Wissenschaften
IMS-FHS | Poststrasse 28 | Postfach 1664 | 9001 St.Gallen | Switzerland
FHO Fachhochschule Ostschweiz_______________________________________________
amp-dev mailing list
amp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/amp-dev
_______________________________________________
amp-dev mailing list
amp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/amp-dev
________________________________________________________________
Urs Frei, Ingenieur FH
Wissenschaftlicher Mitarbeiter
Fon +41 71 226 12 22
Fax +41 71 226 12 13
Web http://www.fhsg.ch
FHS St.Gallen, Hochschule für Angewandte Wissenschaften
IMS-FHS | Poststrasse 28 | Postfach 1664 | 9001 St.Gallen | Switzerland
FHO Fachhochschule Ostschweiz_______________________________________________
amp-dev mailing list
amp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/amp-dev