Any interest in an auto-update script?

Hi, all!

Do you sell a scripted object widely? Do you offer free updates for that object? Do you find it a major pain to manually update all your buyers?

My signature toy, Pixel, auto-updates himself. Whenever you rez the 'Pixel Remote' bracelet (the thing that actually rezzes Pixel), it checks to see if a new version is available. If so, the user gets a pop-up dialog telling her so, with a short blurb describing the update, and she can then click 'Yes' to receive the update, or 'Later' to ignore it. If she clicks 'Yes', the new version is automatically transfered to her inventory.

If there is enough interest, I'm considering selling my auto-update system. It would be by a one-time license fee, for which you receive all permissions to the scripts involved. I'd also help you set up the system, including helping you make any changes you wanted.

I'm not sure what to charge for this. Since I'd be letting my cat out of the bag, so to speak, and sharing what has been a tremendous advantage to me, and since I'd be licensing full mod permissions, I would need to charge enough to justify it. But I can't charge so much that it wipes out your sales profits, thus destroying your desire to have this feature.

I'm prompted to put my toe in this water because of Francis's recent posts regarding having to update all of his/her(?) gun buyers.

This feature has given me tremendous freedom to update Pixel whenever I want. I can make a quicky change based on customer input, without thinking "OMG, it's just not worth the pain of manually dropping all my buyers a new copy."

So, what do you think? Would you like this feature? Would it make your life as a builder/scripter easier? How much would you be willing to pay for it -- what's fair for us both?

If you'd like a demo of this system in action, just IM me.

Thanks!

Does it update the object's inventory, or the agen't inventory where the agent has to manually drag the scripts to the object?

Ooo, a question! And a good one!

The thing that is updated is the object containing the auto-update script. So the buyer gets the object, and all its contents.

In Pixel's case, the object being updated is actually the Pixel Remote bracelet, which itself contains several scripts, and a copy of Pixel (and he contains MONDO scripts). So the buyer gets an updated bracelet, and an updated Pixel.

In the more simple case, like my new 'Naughy Thoughts' project, the buyer would get the 'Naughty Thoughts' object, and the scripts it contains (one of which is the auto-updater script).

Clearer? Or have I slipped into gibberish again?

LOL!!!

Well, let me let the cat out of the bag now, and say the "big feature" that I was going to do for the next Seburo was an auto-update feature. I didn't realize that anyone else had done something like this

The truth of the matter is this:
1) I try to build things the best I can the first time around. The last Seburo update was prompted by LSL changes in 1.4. The next one will be to exploit the new features that came from 1.4.

2) I prefer to do updates by hand. It's a personal touch I like to add, which I feel is valuable. But the reality of the situation is, this takes a lot of time.

The last time I sent out an update, it took a few hours of serious not fun, hitting people in finder, sending them an update, and typing up a short message.

The next update promises to be even more time consuming, because the user-base has grown to the point where it's far too unmanageable.

I have not yet started coding this feature, but I don't think it'll be too hard. I plan to make use of the email subsystem, and exploit the fact that llGiveInventoryList can target all avatars, online or off.

However, if your prices are reasonable, I may be tempted to save myself the time and just license your script. So! Please describe what you're offering in more detail, how it works, and prices if you will!

I might be interested, also.

This is too funny!

OK, I have indeed tapped into a wanted feature. As I quickly discovered with Pixel, once your installed base goes beyond a few beta testers and early adopters to wide release, you are in big trouble doing updates.

Francis, in my previous posts I described what my auto-update script is doning from the buyer's point-of-view. The rest of the system behaves pretty much as you have envisioned in your post. If I said any more than that, I'd be laying out a blueprint for doing it, and that would kinda defeat my idea of licensing my system.

Please understand... I'm not claiming ownership of the IDEA. To the best of my knowledge, it's been done at least twice before. And from your post, it's pretty clear you could do it yourself, too. I know there are much better scripters out there than me. I think having auto-update out in SL for use would really improve things for us scripters, and for the buyers of our stuff, too. Some of you clever people are gonna roll your own system.

But I already have a working system. I also tied it into my Pixel vendors, so that THEY also always sell the latest version of Pixel. And also offer up the latest version of Pixel's free manual.

Anyway, for those of you who don't want the 'adventure' of inventing this feature yourself, what would you be willing to pay for it? I want to come up with a price that's fair, and which will promote wide adoption, 'cause SL needs this.

If everyone tells me that it's worth L$10, and you think that's a fair return for my work, that's what it'll be.

Not having seen/used the script, based solely on your description of its functionality, and not having any idea how easy/difficult it would be to modify for a specific purpose, I absolutely wouldn't even consider going below L$500, and I'd most likely be looking North of L$1000.

That said, assuming it works well "out of the box," is relatively easy to configure/modify, etc, etc, and having seen Pixel a long time ago, even though I don't own one, I'd probably start the negotiations at L$2500 if I were you.

We are, after all, talking about a blueprint license to some pretty impressive scripting. (Assuming the blueprint license includes the right to sell modified one-off versions that may or may not be attached to specific merchandise.)

I've paid more than RL$10 for closed-source single-usage classes/libraries just because I didn't feel like writing the parsing code myself. RL$10 for a blueprint license is pocket change compared to the potential ROI.

If I do this, I mean to sell you a license to use this any way you want. Mod it, copy it, make derivative works from it, put it in any and all of your products.

I mean, this is us scripters, right. I have no interest in ripping you guys off. If I sell you a license to use this, and you think "OMG, this is crap!"... well, I'll happily give you your money back. And apologize. Maybe even cry a bit.

I'm interested in hearing more opinions on this. That probably means waiting til this evening.

Please, I'll be happy to answer questions and show you how this system works. Just IM me. I'll be available after about 6:00 PM EST tonight. I'll probably be listening to Crow's yummy reading of 'Snow Crash'.

Well, I mean I know what a monitor pixel is, but what is this neato Pixel you speak of? Sounds like a pet of some sort? How much and where can one get one/demo it? I'm at work and would love some pictures. Thanks, and sorry for the OT mini-hijack ... but a hijack that brings you business is a good thing, right?

IM me in-world this evening (EST). Pixel would just love to show off.

How to properly update your wares:
1) Put up a new version for sale
2) Advertise
3) Let people buy it again
4) If anybody whines, give them a free copy or a refund, and tell them they are your most valued customer and that sort of mushy marketing stuff.

Heheh cool... I remember meeting Pixel last August, sometime in my first week here....

I haven't seen it since, and only saw you once, Radium, since... I kinda thought you'd left and/or had given up on Pixel...

A few of my own toys were based on what I saw in those first days ...

Sio

Well, I've always viewed overall descriptions of things as value-less. It's the time and effort of making an idea a reality.

And, due to the nature of the problem, I think it's important that you describe how it works so that we can decide the value of the solution.

For example, does this system work in SL only? Or do you require an outside server? How complex is it? Lines of code? How does the system handle flash crowds? What is the latency of the system? If it's inside SL only, I assume you rely on a keyed object. What if that object disappears?

As for self-updating vendors, I'm trying to avoid vendors as much as possible. The "pay" semantics are such a kludge, from a UI point of view. I wish we could hook into a "buy" event in a script.

Of course, I have a self-interest in this. Either I'm going to buy a license for your code, or I'm going to write it myself.

I've worked on a worldwide notecard distribution system that would work similiarly to how I think this system works.

> Central inworld Server that receives emails from the object to update.
> Object sends email to central server via [email]uuid@lsl.secondlife.com[/email]
> Central Server responds by sending updated object if an update is available.

I worry about the same issues as you put through.

What is the latency? Depends on how many update requests would be coming in at any one time (i.e. how many emails to process). My system checks every 5 seconds for new emails, so the latency can generally be anywhere between 1 and 5 seconds, but generally around 10 seconds in practice. Longer depending on factors of "flooding" as you propose.

What if the server object disappears?
I haven't implemented a failsafe for this type of "disaster". The way I'm planning on revising my system is to have a "backup" server on the outside of SL. It wouldn't run unless the "disaster" ocurred.

If a disaster ocurred, you would turn it on, and it would receive emails from the inworld objects, in case they couldn't contact the inworld server. The objects would be configured to talk to the outworld server in case the inworld server didn't send back an acknowledgement email. The outworld server would send back the uuid of the replacement server to the objects, once that replacement has been setup and configured.

A totally inworld system, while not as foolproof as an outworld system, would be to setup multiple servers in multiple locations of SL, and have the objects talk to a random server. If they don't find one, talk to another one. The list of servers would be dynamic, as the object would store the list of servers it knows about.

I generally prefer totally inworld solutions if possible, though an outworld solution for disasters would be easier to implement since you don't have to worry about maintaining multiple backup locations to house servers.

First, my bad. I posted my response to Francis as a new thread, rather than a reply. Oopsie!

Hi, Hank! Those are some good ideas. I like your idea of multiple redundant in-world master objects. Mind if I steal that?

I'm actually relieved to hear that there are others who have thought of these problems and limitations. Now I know I'm not insane, or stupid.

As for latency, it's not a problem for me. It really doesn't matter if a notification of an available update is delayed by a few seconds, or a few minutes. And since the email system acts as a queue for update requests, I also don't worry about a 'burst' of activity coming in. They are all nicely serialized, and handled one-after-the-other until there are no more.

Even the worst case of a request being dropped is OK, 'cause the check for a new update is done every time the object with the auto-update script is rezzed. So, if it's a worn object, that means on every TP, for instance.

Sure, there are other uses of object-to-object comms where latency can be a problem. But until they give use object-to-object XML-RPC or some other system, email or listen is all we have to work with. Fortunately for me, email fits my problem domain spiffily.

Thank you all for your very thoughtful replies!

Oh, one other thing I wanted to ask was if you handled authentication.

But, as for the "it emails my server" blabla. Are you selling access to your server resources outside SL?

The outline of my plan was basically to make everything in-world. Mostly, because I know I'm changing IPs in the near future.

I figured it'd be a 1-way communication system, easier that way. You'd have an MD5 signature based on the username and some secret code, so replay attacks are not possible. It'd send off 2 emails, 1 to a "live" update server, and 1 to a "backup" update server that's not turned on. Once the client script has sent these emails, it's done its job. Everything else is handled by the server, which sends an IM, and offers the update.

Another approach that I would actually prefer is to have a database of all keys of my customers. Then you could implement these this whole upgrade process as a "push" not a "pull" architecture. But, lack of persistant storage requires an outside server, which I won't always have.

Hi again, Francis.

(Looks like I'm working late today. I won't be in-world probably until 8:00 PM EST)

No, I have no plans to sell off-world server services. That's just beyond what I can handle. I believe there are others who have already advertised such services here, thought.

Yes, I have thought hard about authentication, and it's something I should do, but I haven't yet. What you said is exactly right, about using an MD5 signature. That's the way I'd do it.

I think authentication is something that WOULD be needed for a release version of my system. Fortunately, it's very easy to add.

So far, my auto-update system has been robust, and has taken a big load off my shoulders WRT updating all my Pixel owners. It's kinda fun to read thru my RL email and see all the update reports. Gives me a 'happy feet' feeling, knowing all the owners are being taken care of.

Just as a solution to that "perpetual object UUID" ordeal that I have utilized for projects was have an email forwarding account forward to whatever is in-world/out-world server is.

Alondria,

Is this a free service? Is it reliable? I wanted to do this, but I'm changing institutions real soon now, and my bank of IP addresses will be changed in the near future.

So, as for the auto-update thing, I've gone ahead and implemented it.

Basically, my design was this:
- Object emails 3 different perpetual addresses, each signed with an MD5. You can replay all you want, you just get more copies of the same object
- 2 of those 3 perpetual objects are just zombies. Just in case they get somehow deleted. The perpetual objects act solely as email relays. They CC my off-world account, and forward to the real update server. I did this because I wanted to keep the perpetual node as simple as possible, and make it easy to "cut over" to a real server. The truth is, it's faaar too easy to delete a prim by accident when you really wanted to delete the contents.
- Update server validates email, sends out updates. Fun fact: llGiveInventory works across SIMs, llGiveInventoryList does not usually.

It's kind of a cute set up. Notecards to configure everything. Drop and go

There are many free mail forwarders.. or if you need, I can hook you up with one on one of my domains...