...or if it's owned by someone else (which i would consider a feature).

Are UUIDs reused?, That rather defeats the purpose of unique ids and the guid space is larger than we'd "ever" need so it seems unnecessary from an implementation standpoint..

I suspect that the issue is more likely that the UUID of rezzed objects in a simulator is not tracked centrally, so finding the object would mean a global search of the grid - since objects don't have a log in like we agents. Would llMessageObject(string Region, key id, string message) solve this?

However, I get the feeling that we are both speculating

I'm asking for a feature that will send an object to object message and not have to hack it using email - In order to use either SVC1086 or xml-rpc you need to run and support a webserver externally and it so just increases the complexity of this straightforward capability rather than reducing it.

// In the receiver, register to receive IPC:
key listen_id = llAcceptIPC();
//...
dataserver(key id, string msg)
{
  if(id == listen_id) {
    doSomethingWith(msg);
    llReplyIPC(some_string); // Send a response IPC to the sender of the current message
  }
}

// In the sender, look up the object, delays script 5s if region is "":
key prim_id = llSetupIPC(string region, key object_id);
if(prim_id != NULL_KEY) { // NULL_KEY if lookup fails
  llSendIPC(prim_id, some_string); // Send an IPC to a connected prim
}
//...
dataserver(key id, string msg)
{
  if(id == prim_id) {
    if(msg == "") { // Empty reply message means the message was lost
      prim_id = NULL_KEY;
    } else {
      doSomethingWith(msg);
    }
  }
}

If the receiver is alive but doesn't call llReplyIPC, there will be no dataserver reply. It's up to the programmer to decide whether the normal communication is one-way (reply only if the handle becomes invalid [eg, server prim reset, derezzed, or moved to another region]) or two-way. If the message is lost at a low level (eg, sim restarting, congestion) there would be no reply message.

1) There's four new library functions here for LL to implement rather than just one, and also I'm not sure the "setup overhead" is high enough to warrant this complexity (for the reasons stated in the description/comments in this ticket).

2) In all current llRequest... calls, the convention of the key returned to dataserver is generally that it's a per query "transaction" key, rather than a persistent key returning multiple data at arbitrary points in the future..

3) If your proposal or even the proposed llMessageObject is too hard... then I'm wondering whether llRemoteRegionSay(string region, integer channel, string message) may be more feasible for LL to implement? It's not exactly what I had in mind but would be simple to do and would at least be a major improvement over a timer polling llGetEmail!

Regs,
/esc

That's a good point on dataserver, I was thinking in terms of the behavior of http_server and email events, and I suppose it would be cleaner to have an ipc_server event:

// In the receiver, register to receive IPC:
llAcceptIPC();
//...
// Source is an ipc_id for the reply message, it is not the UUID of the originating prim.
ipc_server(key source, string msg)
{
    doSomethingWith(msg);
    llSendIPC(source, some_string); // Send a response IPC to the sender of the current message
}

// In the sender, look up the object, delays script 5s if region is "":
key ipc_id = llConnectIPC(string region, key object_id);
if(ipc_id != NULL_KEY) { // NULL_KEY if lookup fails
  llSendIPC(ipc_id, some_string); // Send an IPC to a connected prim
}
//...
ipc_server(key id, string msg)
{
  if(id == ipc_id) {
    if(msg == "") { // Empty reply message means the message was lost
      ipc_id = NULL_KEY;
    } else {
      doSomethingWith(msg);
    }
  }
}

Of course you wouldn't call socket/listen for each prim that called llAcceptIPC, rather you would have a single listener process on the sim that would be responsible for maintaining a list of prims that had registered as a listener, forwarding llSendIPC requests, and (if the region parameter is optional) communicating with the central registry. Writing such a handler in Perl, Tcl, or Python would be no more than a day's work.

An alternative solution, now that I've looked at llEmail again, would be this:

default {
    state_entry() {
        llEmailServer();
    }

    email(string time, string address, string subj, string message, integer num_left) {
         llOwnerSay("I got an email: " + subj + "\n" + message);
    }
}

Also, looking at the llEmailServer example in the LSL wiki, wouldn't this make the existing API more efficient?

default {
  state_entry()
  {
    llSetTimerEvent(10); // Email isn't super-fast, you know.
  }
 
  timer()
  {
    llGetNextEmail("", ""); //Check for emails
  }
 
  email(string time, string address, string subj, string message, integer num_left)
  {
    llOwnerSay("I got an email: " + subj + "\n" + message);
    if(num_left > 0)
      llGetNextEmail("", "");
  }
}

Why wouldn't this code work? Does the sim actually run the email() event from llGetNextEmail() directly rather than doing it in the event queue? o_O;;;

I find myself asking why llGetNextEmail is required at all, and am concluding that there's something wrong with the way the email event is triggered. Why isn't the code just... e.g.

default {
    email(string time, string address, string subj, string message) 
    {
        llOwnerSay("I got an email: " + subj + "\n" + message);
    }
}

I assume this is because the receiving sim is a client of the MTA, and acts like a standard POP3 client. Hence if the sim decides (which it frequently does) to stop requesting mail, then the queue backs up on the SMTP servers (note – the reason i think this is correct is that a sim restart often re-registers its mail client and you get a stream of previously undelivered messages suddenly come through).

I guess this is a long way of saying that llEmailServer()/llAcceptEmail() would indeed be a way to "register" the object with the sim as a client of the MTA and have the sim poll the server if that list of registered clients isn't empty...?

llMessage(key target, integer num, string str, key id);

If it's not too computationally expensive to send a linked message within an object, then it is not too computationally expensive to send a message to a given UUID within a sim.

Object email should do this, but it doesn't, because for some reason LL wants to bring in all the overhead of a mail subsystem.

Further, prims/objects would, by default, not receive these messages, and be required to do something like llReceiveMessages(TRUE); to start. Then the prim could turn them off if so desired by sending FALSE to the same function.

The addition of these two functions would allow all sorts of duct-tape laggy workarounds to be abandoned in favor of elegant code. How can it possibly be better to, for instance, hash your own UUID, send it to a rezzed object in the start parameter, have the rezzed object do a scan of all nearby prims, loop through them, hash their UUIDs, compare the hash to the start param, and then finally know it's parent..... How can that be better than llMessage(childUUID, timeToDie, "iamyourparent", llGetKey());?

It seems like all that LSL bytecode would be ten times more wasteful than the couple of SQL calls required to find a prim in a sim by UUID. That's what has to be happening for linked messages, and linked messages aren't ever cited as laggy.