permanent UUID channel for XML-RPC

[nikolsy]

Hi.
I am experimenting with some XML-RPC scripts and I have some questions.

the problem is that these UUID channels are generated automatically by the script, but, they change automatically when
    the object goes into inventory
    the region has changes
    they cross to another region.

Is it possible to create permanent channel UUIDs ?.

Similar to the system used by email, where you only have to use the object's UUID (which is permanent)

[Wulfie Reanimator]

By "UUID channel" do you mean just "UUID"? Second Life has UUIDs and channels, but an UUID channel is not a thing.

But no, every instance of an object has a unique UUID and this behavior is one of the foundational design choices of Second Life. Everything that exists on SL is based on it. If you need a permanent identifier, you'll have to come up with your own.

[nikolsy]

In particular, I talk about this function

llOpenRemoteDataChannel()

(you can find information here -- wiki.secondlife.)

 

This function generates a code very similar to a UUID, which is a channel for XML-RPC communication

But that code, which I have called UUID to simplify, it is volatile, as I have already commented in the previous post. So, I ask if there is any way to create a permanent XML-RPC channel (a permanent UUID).

I understand the difference between a permanent UUID, as I discussed earlier, the example of an object UUID, used for llEmail events.

But these XML-RPC channels are mysterious. For example, when you use the llHttpRequest function, it generates a UUID. And if you reset the script, then llHttpRequest function generates a different UUID. Instead, the XML-RPC UUID is the same when you reset the script, but changes when it happens some conditions, for example:

reset region,

save in inventory,

cross region

 

Do you understand me?

 

[nikolsy]

32 minutes ago, Wulfie Reanimator said:

If you need a permanent identifier, you'll have to come up with your own.

what do you mean by this ??

do you know how to create a permanent identifier?

Edited December 29, 2020 by nikolsy

[Wulfie Reanimator]

1 hour ago, nikolsy said:

In particular, I talk about this function

llOpenRemoteDataChannel()

Ah, sorry, I wasn't aware of that function.

But it seems like the only case where it will get the same data channel is when the object changes region.

The caveats also say:

• XML-RPC should not be used anymore. Use http-in instead, see LSL_http_server.
• Note: XML-RPC requests often time-out due to the front-end server being overloaded. LL has continued to upgrade the server hardware periodically, but it has remained unreliable. LL developers have advised that the XML-RPC design isn't scalable (due to the single server bottle-neck) and that the service is "deprecated". They suggest using HTTP Polling as an alternative.

1 hour ago, nikolsy said:

what do you mean by this ??

do you know how to create a permanent identifier?

I mean coming up with your own system of identifying an object. Perhaps by giving each object a unique ID that you determine yourself from your server.

[Fritigern Gothly]

I have never used or looked into llOpenRemoteDataChannel, but if you want to use a UUID as the basis for a channel, then perhaps you could look into this:
http://wiki.secondlife.com/wiki/UUID2Channel

I use the routine with the app key a lot. Not only does that allow me to have different people with a copy of the same item on the same parcel, it even allows me to have a different (but predictable!) channel for each item that I have made, without the risk of my HUD trying to control your item 🙂

Edited December 30, 2020 by Fritigern Gothly

[nikolsy]

well, thanks for answering but ....I think you are not understanding me 😢

I'm going to use an example with a more known function to try to be understood..

 

1º. you've a prim in SL with a script that uses the llHTTPRequest() function

2º. this function generates an http://

for example this:

http://example/lslhttp/d9eerpdlse-ddsa-erfs-dfer-34dfrswsg

(note that the last part of the http is a UUID)

 

3º. This address can be used by functions external to SL(for example jQuery), to have communication with the prim from outside SL

 

4º. if you reset the script (for some reason), then  llHTTPRequest() generates a new address, for example

http://example/lslhttp/00000p00-000a-e00s-110r-300011sg

Quote

 

note that :

part permanent == "http://example/lslhttp/"

part non-permanent == "00000p00-000a-e00s-110r-300011sg"

 

5º. the problem is that now you cannot communicate from the outside SL, the connection has been lost.

 

6º. the solution is to manually replace the new address in your code external to SL.

if you've a single prim, it's not a big problem. But if you've more than 10 prims with different http://... then you've to replace many http: //...

 

I hope the example has been understood...

Now, I'm asking if there is any way for the function that generates the UUID, in this case llHTTPRequest(), not to generate a UUID new one every time a change originates.

Is it possible to use the initial UUID..."forever"? 

 

=== IMPORTANT !!

Finally, remember that this is just an example to illustrate. Actually, I'm asking about the llOpenRemoteDataChannel() function .., but in a way,  llHTTPRequest() and llOpenRemoteDataChannel() have a similar behavior, so, the solution for one function, maybe it works for the other

 

Edited December 30, 2020 by nikolsy

[nikolsy]

an interesting difference between both functions

0º. you've two prims.. Each prim has a different function that is activated by clicking on the prim

 

1º. you touch the first click and the result is this

llHTTPRequest() id = 00000000-0000-0000-0000-0000000

llOpenRemoteDataChannel() id = 00000000-0000-0000-0000-0000000

 

2º. you touch the second click and the result is this

llHTTPRequest() id = 1111111-0000-0000-0000-0000000

llOpenRemoteDataChannel() id = 00000000-0000-0000-0000-0000000

 

3º. you touch the third click and the result is this

llHTTPRequest() id = 1111111-1111-1111-1111-0000000

llOpenRemoteDataChannel() id = 00000000-0000-0000-0000-0000000

observe how that llHTTPRequest() changes with each click, instead the llOpenRemoteDataChannel is able to keep the previous UUID.

this is the behavior i am looking for. Unfortunately, llOpenRemoteDataChannel will change its UUID when there are region changes

 

I would like to know where that UUID is stored, is it in the region?

if llOpenRemoteDataChannel is able to store the UUID in the region then it may be able to store in some other location

 

 

[Wulfie Reanimator]

Unfortunately the answer seems to be no, there's no way to have a permanent "address" within SL.

5 hours ago, nikolsy said:

6º. the solution is to manually replace the new address in your code external to SL.

if you've a single prim, it's not a big problem. But if you've more than 10 prims with different http://... then you've to replace many http: //...

If you have a server, which should have a permanent address, you don't have to do this by hand.

Instead, whenever an object gets a new address, the object can contact your external server and say "hey, this is my new address!"

This way, everything can be done automatically regardless of what happens.

4 hours ago, nikolsy said:

observe how that llHTTPRequest() changes with each click, instead the llOpenRemoteDataChannel is able to keep the previous UUID.

this is the behavior i am looking for. Unfortunately, llOpenRemoteDataChannel will change its UUID when there are region changes

 

I would like to know where that UUID is stored, is it in the region?

if llOpenRemoteDataChannel is able to store the UUID in the region then it may be able to store in some other location

It seems like llOpenRemoteDataChannel assigns an address to the UUID of the object. As long as the UUID of the object doesn't change, llOpenRemoteDataChannel will keep the same address. But as soon as almost anything happens to the object, it will get a new UUID and is no longer recognized as the same object. This means that llOpenRemoteDataChannel has to give it a new address, it has no other option.

[nikolsy]

thanks for answering. Now I have the impression that you have understood me.

According to my previous examples where I compare both functions, for practical purposes, the llOpenRemoteDataChannel() function is more stable than  llHTTPRequest()  because if you have to make some modification in the script of the prim that provides the UUID, it does not change the UUID associated with the link, therefore, communication with the exterior of SL is maintained, without the need to use a server.

 

I don't understand why Linden Lab advises against the use of llOpenRemoteDataChannel(). Rather, I think that the llHTTPRequest() function has to learn from llOpenRemoteDataChannel(), for example "copy a similar behavior. about maintaining supplied UUIDs". This was going to be a plus point

Edited December 31, 2020 by nikolsy

[nikolsy]

On the other hand, about having a server and using a script that communicates with it to report changes and, from this system, maintain a permanent link ... It seems interesting, as long as the objective is reached.

Let us remember the objective pursued. The communication between a prim and the outside of SecondLife, does not have to be lost, as a result of changes in the region.

unfortunately for me, I don't have experience with servers, php programming.. . I use Windows as the operating system. But, if the procedure is not overly complicated, I can try setting up a server. You can provide me with some simple example?. (If possible, a free option for a first test.)

 

[nikolsy]

I am not surprised to find users like you, "Wulfie Reanimator" , unfortunately there are many of on the internet. Their behavior is identical, they say they know the solution to a problem, but when you ask them for the solution in particular, they disappear.

[Mollymews]

On 12/31/2020 at 6:15 PM, nikolsy said:

I don't understand why Linden Lab advises against the use of llOpenRemoteDataChannel(). Rather, I think that the llHTTPRequest() function has to learn from llOpenRemoteDataChannel(), for example "copy a similar behavior. about maintaining supplied UUIDs". This was going to be a plus point

Wulfie already posted the info: LL developers have advised that the XML-RPC design isn't scalable (due to the single server bottle-neck) and that the service is "deprecated".

should you want Linden to implement your advocated changes then best to submit a feature request JIRA: https://jira.secondlife.com/secure/Dashboard.jspa

 

[nikolsy]

your partner wrote

On 12/30/2020 at 1:45 PM, Wulfie Reanimator said:

Instead, whenever an object gets a new address, the object can contact your external server and say "hey, this is my new address!"

and ... of course, it's easy to say anything.

I can say that when you disconnect from secondlife, then a prim with UUID:1111111-1111-1111-1111-0000000,  becomes Santa Claus and with his sleigh he visits my house to give me a beautiful mansion as a gift

 

then you tell me ;" Hey ..Do you have that script?"
but..I disappear

[nikolsy]

on the other hand, squire of wulfie Reanimator, I sent this post to ask users if they know of any alternative solution.
If we all think like you,then this forum does not exist, because we will send messages to Linden Lab.
Fortunately, not everyone is like you, who responds in the simplest way.

Edited January 2, 2021 by nikolsy

[Mollymews]

1 minute ago, nikolsy said:

I sent this post to ask users if they know of any alternative solution.

the alternative for new works is to use HTTP as Linden recommends and not use a function that Linden has deprecated

the only reason the XML-RPC server is still running is because some older existing scripts use it and Linden have a policy to not break existing content

[nikolsy]

anyway, use one function or the other, the problem is the same. How to keep the UUID ?.
Your partner has proposed an alternative,

19 minutes ago, nikolsy said:

Instead, whenever an object gets a new address, the object can contact your external server and say "hey, this is my new address!"

but to date, only theoretical, because I'm waiting for a practical example, it has never come.

you understand me?

 

[Mollymews]

8 minutes ago, nikolsy said:

anyway, use one function or the other, the problem is the same. How to keep the UUID ?.
Your partner has proposed an alternative,

but to date, only theoretical, because I'm waiting for a practical example, it has never come.

you understand me?

 

 

the way this LSL scripting sub-forum works is that you write a script then come on the forum and ask why your script that you have written is not working as  you intend

if you want somebody else to write the script for you then post in Wanted sub-forum for somebody to do this for you, or if you are happy to pay somebody to do it for you then post in Inworld Employment sub-forum

this said

1) there is a scripted rezzed object called "A"

2) there is a second scripted rezzed object called "B"

3) there is a HTTP server that you own/control. Object "A" and object "B" know the address of the HTTP server

4) the UUID (address) of both "A" and "B" can change

5) "A" tells the HTTP server that "I used to be "This UUID", I am now "This New UUID"

6) the HTTP server tells "B" the new UUID/address of "A". "B" can now communicate directly with "A"

if you want somebody to code this up for you then post in Wanted or Inworld Employment