YAQ about product auto-updaters

I know this will look stupid to some of you (!) but I'm only just beginning to teach myself about remote procedure calls & such - I can't properly read the available update server scripts, never mind configure my own.

What I'm hoping for is some pointers to the scripts I *should* be using (PHP/MySQL and LSL) to effect customer product updates when I change the contents of the original. A swift explanation of how the scripts do what they do would be a welcome bonus

Can you help, please?

Edit: maybe I should add specific questions as I limp along with this:-

Q1 => How do I define the external user with access to my db? Is it simply secondlife.com? (Can't test this until I've got a working script, so I need to ask!)

I believe (certainly for mine) version numbers are compared. This takes:

1.) The recipient's object knowing its version (any number of ways of doing that, from prim name/description, to inventory object/script name, to literal data in the script, to...), or possibly a webserver obtaining it automatically from the object name in the HTTP request headers.

2.) Server scripts (either in a server object or on a webserver or both) knowing the version of the object the recipients SHOULD have.

3.) Some logic that compares the versions to determine and remember whether the should-have version is later than the does-have version for a particular recipient, thus becoming an update event.

4.) An (or multiple, if you can tackle the parallel maintenance issues) in-world distribution server that will actually send the object(s) via llGiveInventory().

IMO it is easiest to have almost all the information in the server (a webserver works best, but worst case in your object server scripts, which remain under your direct control), and at most have the dumb script(s) in the distributed objects know and communicate their current version when certain events occur (rez or rez/attach, for example, but touches are common as well). Then the server can hold the key of each resident requiring an update until the distribution server is ready to send it (e.g. polls to dequeue the update data via HTTP).

Thanks, Hewee Any and all guidance is appreciated - for instance, I hadn't even considered that I'd need a second object to serve the script! Oh blimey, that means I'm going to have to fiddle around with in-world script communication & acess PINs doesn't it!

Cherry [need a befuddled-looking smiley here]

I have a simple system that I wrote some time ago for my own products, with quite heavy opt-in, and a more complex system that I wrote for a client, which is more automatic and wider-scale.

Both of them involve version numbers. On rez, with a timeout so that it waits for a while before checking again if rezzed repeatedly, it sends off details of the object and its version number to a server along with an appropriate password, and the server checks to see whether that is the latest one. If it isn't, an in-world distributor object is told to send the latest version to the owner. This of course is only appropriate for copy/no-trans objects.

There are various different ways to set up the communications here. As far as I remember, my personal system just uses the web to check the version number and find the key of the inworld server - it then sends a request directly to the inworld server once it has determined that it is out of date. The more sophisticated version registers that an out-of-date client has checked for an update, and adds a delivery of the new version to the owner to a queue list that it has in a database. The delivery servers then check regularly for queued deliveries, and fulfils them when there are any outstanding ones. This allows for throttling of deliveries and so on.

Hmm. Well, often it is a whole attachment/set of attachments/object, etc., that is sent, but a script could work too. Just make sure you are aware of the limitations of llRemoteLoadScriptPin() and associated functions if you plan to go that route. You're going to need to bring the script to the recipient (llGiveInventory(), or maybe llGiveInventoryList() if you want to require they be "physically" near one of your distribution servers) and have them do some rezzing/stuffing themselves (possibly with the aid of llRemoteLoadScriptPin() to make things easier).

A common solution if you want to deliver a whole object, yet allow the recipient to maintain some settings/preferences for the new version, is to have the object rez a small storage object, communicate settings to it, then reverse the communication with the new update after it is received and attached/rezzed. The Multi Gadget has a good little example of this if I recall correctly. I think you can search for it and get ahold of the manual without buying, which might give you a better picture of the idea.

the one I use is from HippoTech. and the way theirs works, the products call into the website every so often. The website then checks it's records to see if there's an update. if there is, the website phones the server and says "hey this person is using an old version" and then the server sends them the new one.

Pros: this works GREAT for things you might redesign, re-do the model, better textures, whatever. Works well for "complete replacement" projects.

Cons: it TOTALLY SUCKS for transferrable items. it can annoy people who "prefer" the older version, to be sent a replacement copy every time they wear the old item, or whatever.

The contrast though is to systems like XCite uses.. where instead of getting a whole new product, you have to rez a seed and then the seed transfers files to the objects you own. then those scripts alter the object to conform to the new version. This can mean reshaping prims, or just replacing scripts inside.

This kind of system is pretty much USELESS for copyable items. And it's really hard for noobs to understand how to use. (think it's hard telling someone who doesn't speak your language, how to open a box? try explaining this!). The good part with this is, however, it works well with transferrable items, and CAN actually be made to make changes to nomod items as well!

Given the choice, I prefer the "get a new fresh box" while it may be a little annoying to users who refuse to upgrade (there's ways to disable this kind of updating)... it's nice to know that there's less chance for user-error.

The system I use is my own design and is pure LSL, but the way it works is similar to the Hippo version described above - the items regularly check in to the server and say "hey, I'm version x.y", and if there's a new version the server gives it to them. (Actually, they're integrated with the vendors - if you buy something from one of my vendors, the vendor tells the server, "hey, this person has version 0.0" and since there is surely a newer version than that, you are given it as if it were an update).

As has been mentioned though the problem with this method is that the items have to be no-transfer. I have seen some systems that attempt to do auto-updates with transfer-ok items but you have to be very, very careful when writing security for them.

for the uninitiated.. the reason why is this.

Imagine you have a hat, and it's transferrable. Now let's say it's version 1 of the hat. The hat phones home and says "I'm version 1".. the server says "OH! your owner needs version 2.. let me send it" and poof, the owner of the hat now has a version-2 hat. He/Shee then gives the old version 1 hat to a friend. The hat phones home... you can see where this is going.

Many security approaches are tried to solve this issue, from telling the v1 hat to self-delete, to having it go into a "broken" state. Obviously, many of these systems can be defeated. (wearing the hat will keep it from self deleting). Likewise.. if the hat DOES self delete.. there's no guarantee that the person ACCEPTED the v2 hat. In fact there's a possibility that through a mute, or a busy/away state, or some other hiccup of SL, she may never know that a new hat was offered to her!

In the end, no-transfer = easy updates. Yes-transfer = harder for the programmer, and harder for the customer.

Generally, updates are a pain.

My choice was to go with a name-brand system. Besides it was pretty cheap at the time.

Blimey, it's a minefield! I WISH I could afford O.Malaprop's services ... I'm having to put this on hold for a bit, as my RL javascript project is behind schedule (I hate coding!!!) but, certainly, I'm keeping this thread on screen at all times as I know so little and every single post so far has been educational

At this stage, even "it checks with a website" is a ravelled mystery to me Well, I can get a prim to look at a website but after that I'm flummoxed.

I'm also beginning to realise I should not have made the object modifiable (it's a freebie giver, I thought it would be nice for owners to add their own stuffs). Objects can't add items to another item's inventory, right? So, if the buyer has added their own things, an updated version would mean they have to put their own items in all over again. I'll need to figure out the update procedure, then send the owner any new inventory, rather than the entire object ...

My brain's frying

You have to get the prim to look at a .php page, where the script checks and/or updates a database, and then sends a message back in-world to the actual update server if an update is needed. Actually, more of a problem with this is that since XMLRPC still isn't reliable, the actual update server has to poll (yeuch!) the website, which drives up traffic and CPU usage on the web server.



Yes, objects can give to other objects with llGiveInventory, although there are a few restrictions on it.



If the "updates" are actually new freebies to be given out, then it would probably be better to have the list of all available freebies on a web site and have them distributed by a server. This is the system that's used for the freebie walls at NCI (which I scripted).

This is why, even talented builders and scripters.. BUY updater systems from other people.

http://slexchange.com/modules.php?name=Marketplace&file=item&ItemID=177987
L$600, no headaches.

There's a open source one posted someplace here on the forums as well.

True, but the scripts are rarely open for perusal, learning & modification.
Here?
/54/02/171733/1.html
It's a little above my head.

Winter, your effusive reviews of the Hippo server (here and elsewhere) have almost persuaded me to buy one! However, it seems a bit mad to pay L$600 to update a L$35 product, especially as my objective (if I still have one) in all this is to learn stuff .... As it turns out, I've run into a very simple problem that would probably stall the Hippo thing too, unless they do custom fixes.

Right, I'm getting nowhere with this at an incredible speed!

The simple problem is: My object has too many items in it already; it truncates its inventory chat less than a third of the way through its list.

I originally hoped the 'master' copy would tell my Web site its inventory, then PHP could compare that with its current list and - er, well, I'll figure how to actually do the updates later

Then I thought, maybe I can enter the entire current list directly to my db - PHP can tell the prim what its old list was, and LSL can figure out what's changed (never actually done this, but I've seen ListCompareList(?) in there somewhere). But the http response also comes in chat format, so will also be truncated.

I've studied Francisco Saldana's http://rpgstats.com/wiki/index.php?title=LibraryChatCodec Library Chat Codec and I might as well be reading Chinese. I'm more confident with getting PHP to parse its response into 255-character chunks, but how then would I get the SL script to know what to do with the data?

I've been looking at this for far too long, and am suffering severe "can't see wood for trees" syndrome, so any clarity will be very welcome!

Next question, which should be obvious but isn't: My server won't process external data unless it has been specifically told to accept input from a given host. I've only seen ONE reference to what this host should be (in a Wiki entry by Strife O, I think) & can't find it again.

I ran the example script http://rpgstats.com/wiki/index.php?title=ExamplellHTTPRequest and the test prim got back 255 characters of headers & html markup (oops), but PHP registered no avatar data. I assume this is because of my host's security measures.

Does anybody know where, precisely, in-world http requests come from? I'm sure it's not just "secondlife.com".

Edited to add: Looked up the ping my page rceived; result is: 216.82.27.122 sim4911.agni.lindenlab.com.

That wouldn't always be the same, would it?

Thanks for your patience and sterling assistance so far, everybody! I may not have come far, but this is actually quite a long way for me and I know I'm not the only person still battling with this ...

Cheers,
Cherry

If your item is a freebie dispenser, then probably the best bet would be to abandon the idea of having the object hold all the freebies inside itself and then "update" its inventory from a central server. Instead, make the object a "thin client" - when the user clicks to ask for a freebie, it contacts the server to see which freebies are available at that moment, and then contacts an in-world server to give the freebie to the avatar. This is much simpler than updating such an object remotely (a script can give an object to an avatar without having to be in the same sim or worrying about ownership issues), has the same effect and works with the same architecture.

You are so absolutely right, Yumi! I realise this is what you were getting at before; I guess I had to find out the hard way.

It'll still be enough of a challenge to get it working this way

No one mentioned that there's a script in the lslwiki library that allows you to update products without the need of a web server, PHP/SQL etc:

http://lslwiki.net/lslwiki/wakka.php?wakka=LibraryProductUpdateServer2

When object is attached sends a mail to the main object containing last version, if they differ, object is delivered.

Probably it wasn't mentioned because it depends on the assumption that your update server will have the same object key FOREVER, and that's an unsettling assumption to say the least in SL (i.e. absolutely no room for "oops".

There are a remarkable number that use this method, actually. Provided you own your own land or have a safe place, this is not a tool to be discounted, especially for those lacking their own external web resources. Also, you can move the server object to different locations and different sims without losing its current key.

...now... but that wasn't always the case, objects changing sims used to get new keys.

Not really sure this will be the perfect solution, but having no access to an external web server, I am using a variation of the mail-to-server-id method. To that I added a second proximity method (using llSay) that authenticates the object and the current owner using a challenge-handshake. I am a beginner, but seems safe to me, for copy/no trans objects.

This way, should the server object disappear, they still have the option to upgrade by coming to my place.

Actually, I believe you could always keep a key constant by "wearing" the object from in world, tp'ing to the new location, and the "drop"ping it.

Somewhere I still have a snapshot of myself with all of my servers attached to my body..

originally you couldn't even do that which made key communications for attachments a pita on sim crossings, I know telehubs were still around then...

There IS a hybrid solution: use external storage for the key of your server alone. That only requires 36 characters of external web storage (or less--whatever; point being a very small amount of constant data, not storage/bandwith that must scale dramatically with use), and it doesn't really have to be scripted or dynamic web server content (you can copy the key yourself when it changes and upload it to a static text file). This should easily allow you to use free hosting to get SOME of the benefits of a full external storage solution.

That's a good idea, products checks the key from the web. Every time the main 'server' is rezzed it sends the key out-world. That you avoid the change key problem and you don't need a huge database to do that.

EDIT: This brings the question: Why LL doesn't add the option to store simple data in world, it can be a notecard or something else... a field in the object, like I heard around.

Because it could be abused to store huge amounts of data for free.