asynchronous call to appserver from class - is there an even

create external procedure and run it as persistent.

set event response procedure as internal function of this persistent object.

for example:

CREATE asProcs.

RUN callback.p PERSISTENT SET asProcs.hProgress.

AFAIK - not possible.

You can make persistent object call in class constructor and save handle to persistent object as private variable.

Delete object in destructor.

in this case external procedure will be part of class.

I thought it was not possible, that's why I tried to launch it on the communities.

Thanks for your responses !

@ Maxim : the solution you provided, was indeed the way I implemented it for the moment

@Jan : that's exactly what I wanted to know, but I think this is utopia

@Jan : that's exactly what I wanted to know, but I think this is utopia

Did anyone check if there's already something on the ERS for that? I'd like that feature as well. For now I can live with a supporting persistent procedure like done the two of you. When it's nicely encapsulated, I don't have a huge problem with it.

Hey Mike,

I suppose you mean Ehancement Request Site with ERS ?

I did check it and found the below :

G.

Hi Gerd, yes that's the site.

I voted as well now.

Seems to me that this is in a category where votes and business cases should be unnecessary since it is so apparently a case of incompleteness in the OO implementation of the language.  It is one thing to tout the virtue of being able to mix procedureal and OO constructs, e.g., for gradual transition, but another thing to force an OO design to use procedural constructs simply because someone hasn't gotten around to making a statement like this compatable with an OO structure.

We'll not talk about the inability to use/pass objects across the appserver boundary for now... Am I unreasonable to just assume all this will be available in OE11?

Actually, not to hijack this thread, but I think there are really two different levels of possible interaction across an appserver boundary ... or three if you want to include the current abilities and their relationship to use in classes as is the subject of this thread.

So, level 0 is the current call capabilities in the target is a run but the call can come from a class and we have this tacky problem of needing to use a callback *procedure* instead of a method.

The next level is to be able to use OO on the called end.  This is typically described by PSC in terms of being able to NEW and object, call a method on the object, and return the results of that method in a single appserver round trip.

The final level is, as you say, to actually pass an object across the boundary.  I'm not altogether sure this is actually a good idea, however.  It is certainly complex because the actual object in memory is a complex collection of allocations and pointers which are specific to the context of the AVM in which it is found.  It isn't clear how one would pass all that and, after all, one doesn't currently pass a .r across the boundary, so why do we even want to do this?

Note that it is a very different thing to pass the *state* of an object across the appserver boundary and reconstitute the object on the other side (which may or not be the same type of object; it just needs the same signature).  That requires no enhancement of the appserver connection, simply an easy and performant way to serialize the object (see my post in the OO forum on Progress.Lang.Object enhancements).

Note too that good OERA/OO design principles indicate strong separation of responsibilities as perhaps the most key architectural principle.  Clearly, the very existence of an appserver boundary is an extremely dramatic indicator of a layer boundary where we should have strong separation.  Thus, we really should only be passing messages across this boundary, not objects.  In fact, it would be a lot cleaner if AppServer worked more like Sonic, i.e., where a message went to an appropriate service and the service decided what to do with it instead of the current appserver structure where the client actually runs a specific procedure on the appserver, i.e., it knows too much about the implementation.