1  |   Order by default

Nov 9, 1998, 7:49pm

Just fyi (DrChandra, JeanPhi, and Thierry). I've hacked a way to
register event handlers. I'll send it to the list and DrChandra for
comments and such, hopefully this evening.

I'll include a working example as well.

glen
--
glen e. p. ropella =><= Hail Eris!
the swarm corporation W:(505) 995-0818
<gepr at swarm.com> H:(505) 424-0448

Nov 3, 1998, 10:18pm

Hey guys,
In trying to use the AWJNI, I've come across what seems to me a limitation
in the way events are handled in the SDK. I'm not as familiar with event
handling as I should be, though, so correct me if I'm misguided.

Using the C API for the SDK, one designates a handler for an event with
aw_event_set(AW_EVENT_CHAT, foobar);
where
void foobar();

But, using the JNI, I can't actually tell the aw_event_set method in the dll
the handle to use for the procedure to call. I can only give it the jobject
from which it can get the pointer.

So, if I could edit the code that goes into the aw.dll, then I'd be all
set. But, since I can't, I have to find some way to specify to the dll
a constant pointer to call when the event happens and that pointer
referent must make the call into the Java method. Anybody have any
design thoughts on where and how I should do that?

Roland, is there anything I'm leaving out or have
screwed up? If not, is there a convenient way we could put hooks
in for this?

glen
--
glen e. p. ropella =><= Hail Eris!
the swarm corporation W:(505) 995-0818
<gepr at swarm.com> H:(505) 424-0448

Nov 10, 1998, 3:50am

OK. Here's my first cut at adding the events to the awjni that Andrew
published. 1) I didn't do the callbacks; but it should be obvious from
this how the callbacks could be done, 2) I debated using a data structure
to hold the various void xyz(void) event-handler function data; but I don't
think it would have reduced the source bloat, 3) some creepy things
happened to me w.r.t. the java.library.path (which is used by the jvm to
find the non-relocatable libaw.dll) and the $PATH variable (under bash
this is used by GCC to find the aw.dll). But, if you take a look at the
example ConverBot <http://www.swarm.com/aw/ConverBot/ConverBot-0.1.tar.gz>,
it should be obvious how to execute it. Please read the license.txt
<http://www.swarm.com/aw/ConverBot/LICENSE.TXT> before downloading
ConverBot.... it's silly; but it's necessary.

DrChandra, I hope you will be able to fold some of this, in some form, back
into the official release, but until you can get time, I've put the awjni with
my mods up in the parent directory.

Comments are more than welcome!

glen
--
glen e. p. ropella =><= Hail Eris!
the swarm corporation W:(505) 995-0818
<gepr at swarm.com> H:(505) 424-0448

Nov 10, 1998, 7:43pm

[View Quote] > I appreciate any efforts made. Getting the time together to actually "fold
> in" the changes from various sources is somewhat difficult for me. I
> apologize for that. Hey, at least it's open source. :)

You got that Right! Thanks for making the effort.

BTW, I forgot to mention that the event model I used assumes the same
JNIEnv for any events called by the SDK. That means that it all has
to be done in the same thread :-( When we do get around to implementing
callbacks and multiple instances, we'll have to worry about multi-threading.

It wasn't obvious to me how to handle it, since the JNI call NewGlobalRef
didn't like it when I tried to make a global reference out of the JNIEnv.

glen
--
glen e. p. ropella =><= Hail Eris!
the swarm corporation W:(505) 995-0818
<gepr at swarm.com> H:(505) 424-0448

Nov 17, 1998, 5:32pm

Hey!
I've put another version of the Java api for use with Cygnus and jdk 1.2 (sun jvm)
up on our web page <http://www.swarm.com/aw/awjni-0.3-events-querycallback.tar.gz>

I would show you how to use it; but, the clause from the SDK license agreement prevents
me:
-----------------------------------------------------------------------------------------
BETA LIMITATIONS. The Active Worlds SDK is currently Beta Software and
is provided as is for the purposes of evaluation and testing only. By
downloading the beta version of the SDK, you agree to not distribute
the SDK, nor any applications based on the SDK, to any person for any
reason. COF does not to commit to ending the beta testing period by...
-------------------------------------------------------------------------------------

Anyway, rest assured that it works.

I only implemented the aw_query callback. When I get time, I'll put
in the rest (or if somebody else wants to, great) later. Also, I changed
the event_set name from AWevent_set to AWeventSet and AWint_get to
AWint. I did it for really stupid reasons; so don't ask. [grin]

It works with build 9. Roland, did I miss any comments you may have
made about adding the login_email enum type element? Is there a
standard "release notes" place one goes to check for interface changes
to the SDK?

Can't think of anything else.
glen
--
glen e. p. ropella =><= Hail Eris!
the swarm corporation W:(505) 995-0818
<gepr at swarm.com> H:(505) 424-0448

Nov 24, 1998, 9:09pm

Hey guys,

In the "Multiple Instances" section of the docs, the following sentence
could be misleading:

"All API methods operate on the current instance, which means
a multi-instance application must typically call aw_instance_set before
any other method in order to indicate which instance the call is for."

Since I'm dealing with "objectifying" the SDK, I thought this might
imply that one could set different handlers for the same event within
the context of different instances. I think I showed that assumption to be
wrong with an experiment, though. So, apparently only some API
methods refer to a particular instance. aw_event_set isn't one of them.

Am I right in this?

It seems intuitive that only the bot-relevant methods would be
instance specific (e.g. the get/set methods for bools, ints, and strings,
when the attributes involved are bot attribs; destroy; enter; login; etc.)
It might be good to clarify some of this in the Multi-Instance page for
the documentation.

For further reference, I *could* put in multiple instance support into
Java so that the C SDK only saw one handler for each event, but the
Java side would build up a database of handlers and sort through them
as necessary. But, this seems pretty ugly to me. Are there any plans
to make handlers instance dependent? It would also make multiple
bots more efficient if they don't have to crawl through a big switch
statement to decide which piece of code to run. (Of course, it's not
really more efficient in total because the SDK would just take on that
burden; but if we assume the writers of the SDK pay more attention to
efficiency than the Bot writers, then we minimize the chance for
inefficiency. [grin])

glen
--
glen e. p. ropella =><= Hail Eris!
the swarm corporation W:(505) 995-0818
<gepr at swarm.com> H:(505) 424-0448

Nov 26, 1998, 9:46pm

[View Quote] > Ahh, a Java object model. Can I get a look?

Sure. The most recent working version is at
<http://www.swarm.com/aw> in the awjni-blahblahblah file. But, it doesn't
have any multi-instance support. I'm only now debating putting it in. Plus
it's all really dirty. So, I wouldn't recommend reading it.

> The word database seems overkill. All you need is an array of { instance,
> object } that the single installed callback function looks in to work out which
> object to callback.

I tend to use database loosely (to say the least). What I mean here is
to provide the SDK with the ability to store and find handler objects.
That's basic database functionality. Actually I'm using the JGL, which
has things like HashMaps and such. In one of my bots, which I can't
distribute because I agreed tothe sdk license, i use a hash set as
a database of object signatures acquired from the query handler.
They're hashed on 3d space plus object number, which allows me
to do real 3d navigation, instead of 2d columns.

> I wrote a class call Callback and an interface called CallbackAvatarIF. The
> Callback class has a static method that it tells the SDK to call when an event
> is generated. It also has a setEvent(instance, CallbackAvatarIF *) methods
> that allows a robot to install its object as a called back object. Sample using
> Java syntax (if I remember it right)

[...]

> I think this is a very pretty way of routing events to the appropriate object
> and it is essential for any OO SDK to implement such a strategy. If you do not
> implement it then the programmer will have to implement their own anyway for
> every multi-instance bot they create.

This is basically what I did. I provided a set of global procedures for events
and callbacks within the library of native C functions. The SDK calls those
functions. Inside those functions are references to Java methods contained
in Java Objects.

I recently changed this so that there's a EventHandler and a CallbackHandler
interface. That way you can either create new objects to do the handling
or you can just implement the interface with the Bots themselves.

Adding a dbase of handler objects will allow me to execute separate
pieces of code in response to events and callbacks without the use
of switch statements.

>
> Can't be done in c. so I expect this will take a long time.

Yes it can. All that would be required is the administrative
overhead required to pay atttention to the current instance
during the call to event_set. *If* event_set is called before
there is a valid instance, then it could be assumed that the
user purposefully wants all the handlers to be the same for
all the instances. Or better yet, one could set one generic
handler before any bots were created, then for special bots,
a special handler could be set for one or more of them as
they are instantiated.

It would require changes to the event/callback trigger
code and the event/callback setup code; but, it can be done.

glen
--
glen e. p. ropella =><= Hail Eris!
the swarm corporation W:(505) 995-0818
<gepr at swarm.com> H:(505) 424-0448

1  |   Order by default