Prepping an item for possible updates

What is the best way to prep an object for possible future updates?

If an off-the-shelf update system, like Hippo would be the way to go, I'm all for that if it works well.

This is the first item I've made that has the potential to be a "killer-app" as far as SL items go, so I want to make sure I get it right the first time.... and if I don't get it right, I want an easy way to push out updates

Do you have a web server or even just a domain name? Even if you don't setup the server side of things for a while, you could come up with a URL to have your object access on rez, attach, timer, or whatever is appropriate (that won't cause object give SPAM too badly when and if you DO post updates).

The object should include a version number/ID of some sort in the HTTP request, so that a server-side script could compare it to a "latest" version and queue up an inventory give for an in-world helper object to service if the object's version is outdated. That's the only info you'll need to include explicitly; owner name and key (well, key anyway; not ALWAYS name because sometimes it sends the request before the sim can do the name-to-key lookup and you get some kind of "Waiting...)" string for the owner name) are added to the HTTP headers automatically. If you wanted to depend on the version being easily parsed from the (no-modify so the owner can't rename it) object's name, you could even leave the version number out of the request parameters.

For now just have your object-side script ignore HTTP errors silently, though if it does get back a non-erroneous response (HTTP status 2xx) it could print it out as an informative message to the owner (e.g. the server could send "A newer version of <productName> is available and should arrive shortly. Please delete this object once you have received it.". This way you don't have to even have anything in place on a server; just a URL that could be deployed to in the future.

I do have a web server... but I don't see myself tinkering with php anytime soon to write a backend.

Anyone have off the shelf suggestions? Or is there anything I should at a minimum put in the code to allow updates?

Is llSetRemoteScriptAccessPin(pin) anything I should consider? Or is that not related to updates?

You CAN do it with llEmail() to an in-world server object if either A.) you never, EVER take or delete the server object so it keeps the same key (ATTACH it from in-world then DROP it back in-world before logging out to move; DO NOT DETACH IT!), or B.) use something like a file on your webserver to store the key of the in-world server object and have your script retrieve it before sending e-mails requesting update info. The latter would allow you to use the webserver to good advantage with a minimum of stuff on it (you could even just manually upload/edit a text file containing the correct server key on the occasion that it changes).

In that case your product should make an HTTPRequest() to a predetermined URL (again probably ignoring any errors and treating them as "no update available". If it does get content back, it should e-mail the in-world object with that key using 'llEmail((string)serverKey+"@lsl.secondlife.com", ...)', being sure to include its own version and its owner's key in the mail subject or body.

That's it. The server object could take care of the rest. Of course, you might also want to consider security. Make sure you have some kind of content in the e-mail so that you can verify it is a legitimate update (e.g. a password, or better yet the version number, date, and owner key used together with a password to generate a secure hash, just in case the e-mail could be intercepted--which is very doubtful, but...). You wouldn't want someone to guess how to e-mail the server they find in your basement in order to get a free copy of your product.

Hippo's is a very good system.

However I feel that relying on an external service not in my control is a little bit risky, even if dealing with someone well known for excellent service.

I've been using my own very simple system (Made starting from 0 php knowledge!) where the update client sends a request to the server and the server connects to my Gmail via XPertMailer (Free Hosts commonly disable SMTP) to send a mail to the inworld server.

The inworld server sends in its UUID when rezzed or reset.

~~~~~

I would *like* to build a smoother running system using Databases for servers and their inventory, aswell as for the Product/Version system, removing most of the load placed on LL servers... But alas I lack the PHP/MySQL ability and patience to learn that much.

Perhaps a community project for such a thing intended for individual users to implement on their own hosting could be in order.

There's 2 kinds of "updates" and I think you're going to run into some problems unless you do a bit of pre-planning.

Which update method you use, depends largely on the next-owner permissions of your product.



2. Upgrade. Upgrade updating.. is a lot more complicated. Like Replacement, there's a script that does the calling-out and says "hey, I'm version 1"... and like Replacement, you build a doohicky to send them Version 2. But INSTEAD of sending them a brand new package, you send them a sort of viral thing, that they rez. (or you tell them to come to your "update zone" in your sim, and the object then "installs" scripts, prims, whatever into the old item. Then the new scripts delete the old scripts, move prims around, change textures, do whatever they NEED to do, to make the old "Version 1" into "Version 2"

Here's why there's 2 different methods.

If the item is transferrable... then if you "give them a new box" when Version 2 comes out.. they can take the old V1 item, and hand it to a friend, they get the V2 box, hand it to another friend, etc etc.

This is why so many updatable items in Second Life are no-transfer.

If you're selling items that are no-trans, just go for the simple updater. There are some really easy commercial products out there, to help you do your own updates, and they'll handle the whole php backend, and even provide you with scripts you can use or change to fit your needs (hippoUPDATE is the one I use). Then there's no need to mess with all that script-pin-load stuff.

If on the other hand, you're selling a product that *IS* transferrable.. then you've got a MUCH bigger job ahead of you.. and I'm sorry, it's over my head to help.

There's 2 kinds of "updates" and I think you're going to run into some problems unless you do a bit of pre-planning.

Which update method you use, depends largely on the next-owner permissions of your product.

1. Replacement. This is the simplest method of all. The product periodically (or on rez/on demand) dials up a web page, sends an email, or in some other way, "phones home" and says essentially "Hey, Joe User has version 1".

2. Upgrade. Upgrade updating.. is a lot more complicated. Like Replacement, there's a script that does the calling-out and says "hey, I'm version 1"... and like Replacement, you build a doohicky to send them Version 2. But INSTEAD of sending them a brand new package, you send them a sort of viral thing, that they rez. (or you tell them to come to your "update zone" in your sim, and the object then "installs" scripts, prims, whatever into the old item. Then the new scripts delete the old scripts, move prims around, change textures, do whatever they NEED to do, to make the old "Version 1" into "Version 2"

Here's why there's 2 different methods.

If the item is transferrable... then if you "give them a new box" when Version 2 comes out.. they can take the old V1 item, and hand it to a friend, they get the V2 box, hand it to another friend, etc etc.

This is why so many updatable items in Second Life are no-transfer.

If you're selling items that are no-trans, just go for the simple updater. There are some really easy commercial products out there, to help you do your own updates, and they'll handle the whole php backend, and even provide you with scripts you can use or change to fit your needs (hippoUPDATE is the one I use). Then there's no need to mess with all that script-pin-load stuff.

If on the other hand, you're selling a product that *IS* transferrable.. then you've got a MUCH bigger job ahead of you.. and I'm sorry, it's over my head to help.

There's 2 kinds of "updates" and I think you're going to run into some problems unless you do a bit of pre-planning.

Which update method you use, depends largely on the next-owner permissions of your product.

1. Replacement. This is the simplest method of all. The product periodically (or on rez/on demand) dials up a web page, sends an email, or in some other way, "phones home" and says essentially "Hey, Joe User has version 1". Then just create a scripted device to read that email or message, and then automagically sends version 2 to Joe User.

2. Upgrade. Upgrade updating.. is a lot more complicated. Like Replacement, there's a script that does the calling-out and says "hey, I'm version 1"... and like Replacement, you build a doohicky to send them Version 2. But INSTEAD of sending them a brand new package, you send them a sort of viral thing, that they rez. (or you tell them to come to your "update zone" in your sim, and the object then "installs" scripts, prims, whatever into the old item. Then the new scripts delete the old scripts, move prims around, change textures, do whatever they NEED to do, to make the old "Version 1" into "Version 2"

Here's why there's 2 different methods.

If the item is transferrable... then if you "give them a new box" when Version 2 comes out.. they can take the old V1 item, and hand it to a friend, they get the V2 box, hand it to another friend, etc etc.

This is why so many updatable items in Second Life are no-transfer.

If you're selling items that are no-trans, just go for the simple updater. There are some really easy commercial products out there, to help you do your own updates, and they'll handle the whole php backend, and even provide you with scripts you can use or change to fit your needs (hippoUPDATE is the one I use). Then there's no need to mess with all that script-pin-load stuff.

If on the other hand, you're selling a product that *IS* transferrable.. then you've got a MUCH bigger job ahead of you.. and I'm sorry, it's over my head to help.

Hrm, I had indeed overlooked that...

It's late now, tomorrow I'll try to come up with something... But I can't guarantee results.

There's 2 kinds of "updates" and I think you're going to run into some problems unless you do a bit of pre-planning.

Which update method you use, depends largely on the next-owner permissions of your product.

1. Replacement. This is the simplest method of all. The product periodically (or on rez/on demand) dials up a web page, sends an email, or in some other way, "phones home" and says essentially "Hey, Joe User has version 1". device to read that email or message, and then automagically sends version 2 to Joe User.

2. Upgrade. Upgrade updating.. is a lot more complicated. Like Replacement, there's a script that does the calling-out and says "hey, I'm version 1"... and like Replacement, you build a doohicky to send them Version 2. But INSTEAD of sending them a brand new package, you send them a sort of viral thing, that they rez. (or you tell them to come to your "update zone" in your sim, and the object then "installs" scripts, prims, whatever into the old item. Then the new scripts delete the old scripts, move prims around, change textures, do whatever they NEED to do, to make the old "Version 1" into "Version 2"

Here's why there's 2 different methods.

If the item is transferrable... then if you "give them a new box" when Version 2 comes out.. they can take the old V1 item, and hand it to a friend, they get the V2 box, hand it to another friend, etc etc.

This is why so many updatable items in Second Life are no-transfer.

If you're selling items that are no-trans, just go for the simple updater. There are some really easy commercial products out there, to help you do your own updates, and they'll handle the whole php backend, and even provide you with scripts you can use or change to fit your needs (hippoUPDATE is the one I use). Then there's no need to mess with all that script-pin-load stuff.

If on the other hand, you're selling a product that *IS* transferrable.. then you've got a MUCH bigger job ahead of you.. and I'm sorry, it's over my head to help.

Goofed on my last reply.... daughter was logged in last, so I'm re replying again under my nick.

I do have a server, but don't want to fuss with the whole backend.

I had kinda planned all along to do the item as no-trans, mostly because I hate no copy items getting lost and all the support issues that come up from that (OHHHh I could go on about rezzing no copy items in coalesced groups across property bounderies!) Partly because the item isn't something that would typically be "gifted". It would be something you would buy for yourself or your business.

Thanks Winter for the vote of confidence for Hippo. I have a few other Hippo items, and they have always "just worked."

I may just write one. Might even be able to do it in a single PHP script. I'd prefer Perl, but for some reason LSL developers seem to be so majorly hung up on PHP that they aren't even aware other convenient server-side languages and technologies exist.

Wait. Actually, maybe I WILL write it in Perl. Maybe that'll help convince people to step outside their comfy little boxes....

Probably because many free/cheap webhosts don't give you access to a cgi-bin directory (or many beginners can't figure out how to use/access it). Php scripts can usually be run from any directory (when enabled).

Most web hosts I've seen support Perl (5) and allow Perl scripts in any document directory, not just under cgi-bin. Those that don't support Perl scripts should be shot. Those who require it be under a cgi-bin directory may be forgiven, but barely.

Plus, there may be some elements of "php talking to mySQL" that people infer when they say "the php parts"... I'm sure that perl/cgi can do these tasks well, and even a flat file database might be reasonable.. but a lot of people like mySQL.. and there's that whole "permission to write to directory" issue that some hosts get freaky about... and so that kills a lot of text-file database projects.

So it may be that php's easier-to-get-started nature, plus it's more.. common association with sql databases.. that appeals to people.

I'm not sure if cgi/perl *CAN* interface with mySQL.. but I wouldn't be surprised if it can.. I just suspect that most people are in love with php, the same way that the web is all about css and flash nowadays.

Perl's DBI and CGI modules are as complete, as standard, and as easy to use as PHP's. More so IMO. It fits on top of MySQL like a glove. And Perl's taint checking is a VERY GOOD THING for web applications; a feature that PHP cannot begin to rival.

Then bust it out! We're waitin! (I personally dumped all my javascript/perl/php/css/and xhtml stuff out of my brain 3 years ago when I *NEEDED* to learn lsl.

My apologies, I usually say "PHP" to mean any of the coding languages for web systems. I'll try to stop doing that.

Anyway, I'll write the inworld server and client scripts? Though I'm sure you're more qualified than I.

Okay. I'm on it.

Just wanted to let you folks know that I'm still working on this. I haven't forgotten, but I've had a few big RL interrupts over the weekend so it's not being as swift as I had hoped. I decided to make it a little nicer than a simple little one-file script.

I'm about half-way there I think. Which is to say I have SQL scripts for setting up the database, database user, and tables, a pretty good configuration file that lets you modify network security policy, database connection, a few behaviors such as automatic customer registration, and I have entity classes that take care of the low-level database CRUD (literally). Left to go: the high level actions that scripts can call into, and documentation for the HTTP script API.

I'll be calling it "Open SL Product Update Server" and releasing it under the GNU GPL v3 (http://www.gnu.org/licenses/gpl.html). Go Free software!

That's awesome Hewee..I've actually been planning to write my own for a while now, but haven't gotten around to it. Can't wait to try it out!

Hewee to the rescue!

Version 0.1.1 of my Open SL Product Update Server application is complete. I have only done some very basic functionality testing so far (all from the command line using Perl's CGI debug features). I plan on deploying to a web server and doing some more extensive tests in the near future, but I wanted to get out a version you might be able to play with as well.

From the documentation in doc/html/index.html:



Unfortunately, the attach feature in these forums doesn't seem to be working. I may just resort to RapidShare or something for the moment. Stand by and I will get some kind of link posted here shortly.

Hewee: You're fast.

Is it just the webserver end of it, or does it also have inworld Server/Client stuff?

Just the web server for now.

I've got a project pending review on http://sourceforge.net. Hopefully that'll come through quickly so I can get the code out to you guys.