| 1 | *** This is a detail of OAF internals. You do not need to know this information |
|---|
| 2 | in order to write programs that use the OAF API. *** |
|---|
| 3 | |
|---|
| 4 | This whole setup is to allow finding objects that give us initial |
|---|
| 5 | entry to a universe of CORBA objects. The references to these initial |
|---|
| 6 | objects must be bootstrapped out of thin air, so we use well-known |
|---|
| 7 | locations to check if they are running and to make their existence |
|---|
| 8 | known when started. |
|---|
| 9 | |
|---|
| 10 | OAFRegistrationCategory: |
|---|
| 11 | Attributes that an initial object needs to have. |
|---|
| 12 | |
|---|
| 13 | 'name' is the repo ID of the object that would need |
|---|
| 14 | bootstrapping - IOW the object type. Currently this would be |
|---|
| 15 | either IDL:OAF/ActivationContext:1.0 or IDL |
|---|
| 16 | |
|---|
| 17 | 'session_name' is to allow things like two different OD's on the same |
|---|
| 18 | user/host/domain for different $DISPLAY. |
|---|
| 19 | |
|---|
| 20 | 'username', 'hostname' - in the traditional UNIX sense. |
|---|
| 21 | |
|---|
| 22 | 'domain' - I think this was supposed to work like 'session_name'. |
|---|
| 23 | So broken and confusing - need to run through the usage in some |
|---|
| 24 | sample cases to get it right. |
|---|
| 25 | |
|---|
| 26 | OAFRegistrationLocation: |
|---|
| 27 | Provides the implementation of a "well-known location". liboaf comes |
|---|
| 28 | with one that looks in local files in /tmp/orbit-sopwith. gnome-libs |
|---|
| 29 | HEAD has one that looks at a root window property. |
|---|
| 30 | |
|---|
| 31 | OAFServiceActivator: A function that can get called to start an |
|---|
| 32 | initial object if it can't be found by any of the |
|---|
| 33 | OAFRegistrationLocations. gnome-libs defines one of these that tries |
|---|
| 34 | to start oafd on a remote machine via rsh/ssh, but I think I forgot to |
|---|
| 35 | write the accompanying OAFRegistrationLocation that checks for an |
|---|
| 36 | existing one. Or something like that. |
|---|
| 37 | |
|---|
| 38 | OAF handles multiple OAFRegistrationLocations and OAFServiceActivators |
|---|
| 39 | internally. |
|---|
| 40 | |
|---|
| 41 | BUGS: |
|---|
| 42 | |
|---|
| 43 | . You really want to be able to do things like use the |
|---|
| 44 | ActivationContext listed on $DISPLAY even if you aren't in a GUI |
|---|
| 45 | program, or be able to have remote ObjectDirectorys activated even in |
|---|
| 46 | a local non-gnome-libs-HEAD program. The only solution that has |
|---|
| 47 | presented itself so far is to install a shared library for each |
|---|
| 48 | regloc/serviceactivator, then have liboaf run a small program that |
|---|
| 49 | checks all the reglocs and returns the object requested. This is |
|---|
| 50 | slow. This would also have problems if the non-GUI program was run as |
|---|
| 51 | a daemon or something else (e.g. what if you have a BIFF-like program |
|---|
| 52 | that gets run from procmailrc and tries to talk to Your Favorite Mail |
|---|
| 53 | Check Program? $DISPLAY won't be set for /usr/bin/corbabiff) |
|---|
| 54 | |
|---|
| 55 | . Yes, the naming really sucks, but people writing OAF-using programs |
|---|
| 56 | don't have to use this API so it's not too bad. |
|---|
| 57 | |
|---|
| 58 | - ECL |
|---|
