|
If you were logged in you would be able to see more operations.
|
|
|
The HTTP server functionality described in http://wiki.secondlife.com/wiki/LSL_http_server makes it very difficult to host a stable server object in SL. This is because the script must allocate a new temporary URL not only for new object instances, but also if the script is reset, if the sim is restarted, or if the object changes regions.
An obvious solution to this problem would be to use the key of the prim to form a URL. This should work because there is already a need to lookup an object by key on the grid (otherwise even in-world object-to-object e-mail wouldn't work). Speed for HTTP functionality might be an issue, but if LL is serious about implementing this kind of feature, some form of efficient caching could be implemented. This also shouldn't be any more onerous than registering a temporary URL as is currently done for beta.
However, then the question is, "Which script would service any given request if multiple have http_request handlers?" An event-based solution is much more desirable than some kind of polling, not to mention necessary for both performance and to avoid HTTP timeouts, so a llGetNextEmail() type solution is out.
I suggest using a URL that includes both the key of the prim and the URL-encoded name of the script (since a script name is unique within the inventory of its containing prim). Whether the script would still have to request the URL or whether it would be assigned automatically if the script has a http_request handler in the current event is a separate issue and could be addressed elsewhere. This would allow a script to determine its own URL using a simple pattern, llGetKey(), and 'llEscapeURL(llGetScriptName())'.
Example URL pattern: http://lslwww.secondlife.com/<primKey>/<urlEncodedScriptName>
Example URL: http://lslwww.secondlife.com/12341234-1234-1234-1234-123412341234/My%20Http%20Script
IMPORTANT IMPLEMENTATION NOTE: There is nothing about this solution that would need to break existing beta scripts utilizing the functionality, except for the corner case where a script might request multiple URLs (which can be switched to using different path parts or query parameters to handle the same requirement). If the server logic always returns the calculated URL when a URL is requested, any scripts utilizing a single URL can continue to function as-is.
|
|
Description
|
The HTTP server functionality described in http://wiki.secondlife.com/wiki/LSL_http_server makes it very difficult to host a stable server object in SL. This is because the script must allocate a new temporary URL not only for new object instances, but also if the script is reset, if the sim is restarted, or if the object changes regions.
An obvious solution to this problem would be to use the key of the prim to form a URL. This should work because there is already a need to lookup an object by key on the grid (otherwise even in-world object-to-object e-mail wouldn't work). Speed for HTTP functionality might be an issue, but if LL is serious about implementing this kind of feature, some form of efficient caching could be implemented. This also shouldn't be any more onerous than registering a temporary URL as is currently done for beta.
However, then the question is, "Which script would service any given request if multiple have http_request handlers?" An event-based solution is much more desirable than some kind of polling, not to mention necessary for both performance and to avoid HTTP timeouts, so a llGetNextEmail() type solution is out.
I suggest using a URL that includes both the key of the prim and the URL-encoded name of the script (since a script name is unique within the inventory of its containing prim). Whether the script would still have to request the URL or whether it would be assigned automatically if the script has a http_request handler in the current event is a separate issue and could be addressed elsewhere. This would allow a script to determine its own URL using a simple pattern, llGetKey(), and 'llEscapeURL(llGetScriptName())'.
Example URL pattern: http://lslwww.secondlife.com/<primKey>/<urlEncodedScriptName>
Example URL: http://lslwww.secondlife.com/12341234-1234-1234-1234-123412341234/My%20Http%20Script
IMPORTANT IMPLEMENTATION NOTE: There is nothing about this solution that would need to break existing beta scripts utilizing the functionality, except for the corner case where a script might request multiple URLs (which can be switched to using different path parts or query parameters to handle the same requirement). If the server logic always returns the calculated URL when a URL is requested, any scripts utilizing a single URL can continue to function as-is. |
Show » |
made changes - 27/Oct/08 10:05 AM
| Field |
Original Value |
New Value |
|
Link
|
|
This issue duplicates SVC-3238
[ SVC-3238
]
|
made changes - 27/Oct/08 10:05 AM
|
Link
|
This issue duplicates SVC-3238
[ SVC-3238
]
|
|
made changes - 27/Oct/08 10:06 AM
|
Link
|
|
This issue Relates to SVC-3238
[ SVC-3238
]
|
made changes - 27/Oct/08 10:08 AM
|
Link
|
|
This issue Relates to SVC-1086
[ SVC-1086
]
|
made changes - 27/Oct/08 10:13 AM
|
Description
|
The HTTP server functionality described in http://wiki.secondlife.com/wiki/LSL_http_server makes it very difficult to host a stable server object in SL. This is because the script must allocate a new temporary URL not only for new object instances, but also if the script is reset, if the sim is restarted, or if the object changes regions.
An obvious solution to this problem would be to use the key of the prim to form a URL. This should work because there is already a need to lookup an object by key on the grid (otherwise even in-world object-to-object e-mail wouldn't work). Speed for HTTP functionality might be an issue, but if LL is serious about implementing this kind of feature, some form of efficient caching could be implemented.
However, then the question is, "Which script would service any given request if multiple have http_request handlers?" An event-based solution is much more desirable than some kind of polling, not to mention necessary for both performance and to avoid HTTP timeouts, so a llGetNextEmail() type solution is out.
I suggest using a URL that includes both the key of the prim and the URL-encoded name of the script (since a script name is unique within the inventory of its containing prim). Whether the script would still have to request the URL or whether it would be assigned automatically if the script has a http_request handler in the current event is a separate issue and could be addressed elsewhere. This would allow a script to determine its own URL using a simple pattern, llGetKey(), and 'llEscapeURL(llGetScriptName())'.
Example URL pattern: http://lslwww.secondlife.com/<primKey>/<urlEncodedScriptName>
Example URL: http://lslwww.secondlife.com/12341234-1234-1234-1234-123412341234/My%20Http%20Script
IMPORTANT IMPLEMENTATION NOTE: There is nothing about this solution that would need to break existing beta scripts utilizing the functionality, except for the corner case where a script might request multiple URLs (which can be switched to using different path parts or query parameters to handle the same requirement). If the server logic always returns the calculated URL when a URL is requested, any scripts utilizing a single URL can continue to function as-is.
|
The HTTP server functionality described in http://wiki.secondlife.com/wiki/LSL_http_server makes it very difficult to host a stable server object in SL. This is because the script must allocate a new temporary URL not only for new object instances, but also if the script is reset, if the sim is restarted, or if the object changes regions.
An obvious solution to this problem would be to use the key of the prim to form a URL. This should work because there is already a need to lookup an object by key on the grid (otherwise even in-world object-to-object e-mail wouldn't work). Speed for HTTP functionality might be an issue, but if LL is serious about implementing this kind of feature, some form of efficient caching could be implemented. This also shouldn't be any more onerous than registering a temporary URL as is currently done for beta.
However, then the question is, "Which script would service any given request if multiple have http_request handlers?" An event-based solution is much more desirable than some kind of polling, not to mention necessary for both performance and to avoid HTTP timeouts, so a llGetNextEmail() type solution is out.
I suggest using a URL that includes both the key of the prim and the URL-encoded name of the script (since a script name is unique within the inventory of its containing prim). Whether the script would still have to request the URL or whether it would be assigned automatically if the script has a http_request handler in the current event is a separate issue and could be addressed elsewhere. This would allow a script to determine its own URL using a simple pattern, llGetKey(), and 'llEscapeURL(llGetScriptName())'.
Example URL pattern: http://lslwww.secondlife.com/<primKey>/<urlEncodedScriptName>
Example URL: http://lslwww.secondlife.com/12341234-1234-1234-1234-123412341234/My%20Http%20Script
IMPORTANT IMPLEMENTATION NOTE: There is nothing about this solution that would need to break existing beta scripts utilizing the functionality, except for the corner case where a script might request multiple URLs (which can be switched to using different path parts or query parameters to handle the same requirement). If the server logic always returns the calculated URL when a URL is requested, any scripts utilizing a single URL can continue to function as-is.
|
made changes - 28/Oct/08 09:58 AM
|
Status
|
Open
[ 1
]
|
Resolved
[ 5
]
|
|
Resolution
|
|
Won't Finish
[ 2
]
|
|
Assignee
|
|
kelly linden
[ kelly linden
]
|
made changes - 30/Oct/08 03:50 PM
|
Link
|
|
This issue is related to by SVC-3238
[ SVC-3238
]
|
made changes - 30/Oct/08 03:51 PM
|
Link
|
This issue Relates to SVC-3238
[ SVC-3238
]
|
|
made changes - 13/Nov/08 12:11 PM
|
Workflow
|
jira-2007-12-22a
[ 61027
]
|
jira-2008-11-14
[ 82756
]
|
made changes - 13/Nov/08 04:49 PM
|
Workflow
|
jira-2008-11-14
[ 82756
]
|
jira-2008-11-14a
[ 93091
]
|
|
New Feature
Resolved
Normal
Stable URLs for LSL_http_server
http://sim123.agni.lindenlab.com:12031/cap/
That server and port change whenever the region goes offline/restarts or the object changes what region it is on. And tracking that for every object that has an url is not feasible, but would be required of this proposed solution.
So, what would it take to have persistent urls? It would take new hardware which the current implementation doesn't need. It would take a registration call to request a persistent url. It may need to have a small L$ cost for that registration to offset the additional overhead. These new servers would need to get messages to update their forwarding information every time the script was reset, the object changed regions, the object was rezed or the region restarted. In other words these servers would have to do everything that an external forwarding service has to do now. It is possible we could implement such a service in the future if needed, however we fully expect there to be 3rd party solutions by the time this gets out of beta if not much sooner.
Yes, I want persistent urls. The current implementation does not preclude persistent urls. They are possible as a 3rd party service and it is possible for them to be added later with no lost or duplicated work or effort. The current implementation is the simplest solution that works and creates a potential new service for 3rd parties to offer.