Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [amp-dev] Antwort: Re: Antwort: Re: Antwort: Ascape core


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.

"Current Ascape 5.2.0 plugins per https://dev.eclipse.org/ipzilla/show_bug.cgi?id=3302. ***Code is actually maintained at: https://ascape.svn.sourceforge.net/svnroot/ascape/***."

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


Back to the top