Cinder, there doesn't need to be consensus, but APIs should be well thought out and ideally breaking changes should only be made when absolutely necessary. When possible, they should be phased in to give developers a chance to release versions that support the new interfaces before customers see crashes. This did not happen in this case.

Core very quickly implemented a flow to handle land pass sales under the believe that they had all the money module tools they needed. I informed them that they didn't and should take some time to plan this. No planning went into this (other than the research I had published in IRC as to how to capture the land-pass sale flow) before coding was started. They first tried to use the flows that uploading of textures or group creation fees uses. I had to inform them that those don't supply any information for who to pay (the land owner) or any details of the transaction (such as the parcel). They then jumped to using the existing MoveMoney() function, but I informed them that this flow might hand out a land pass when the payment failed as it returned void. They added a new interface function which returns a bool to resolve this. I asked that they add a dictionary arg to this so that information about the transaction could be passed to the money module and so that it might be more flexible for future transaction modifications, but they seemed set on preventing the money module from having access to any info beyond a string description. I asked that they provide a callback function for the money module to call after it had asynchronously completed the transaction (so that the money module could control delivery of the pass), but this was also refused and they went with a flow where the core fully controls the flow.

This could have been done without breaking any money modules by creating a new event in core which the money module could subscribe to. For modules which didn't, this event would be fired and nothing would happen. My other suggestion was that if they add a new interface function, they do it now and announce that they would start using it some number of versions in the future, to give all money modules a chance to implement it. Instead, they added it and immediately began using it.

Further, these changes were made in the 0.9.1-dev branch and really should never have impacted the 0.9.0-release. So, even if you are making breaking changes, those should not end up in a release if they weren't in the release candidates for a version. Sure, core has the ability to do what they want and sometimes moving quickly is the right move. I don't believe they needed to move this quickly here and I believe a lot of bad decisions were made which unnecessarily adversely affected customers.

Thanks Cinder. We're working out butts off.

Right, as the maintainer for a software library, I understand the need for API/ABI stability if you expect any consumers of the library to make effective use of it, but I have a special loathing for the majority of OpenSim money modules, their memory leaks, and their home-brewed security schemes, and will happily see the unmaintained ones obsoleted by improvements.

Thanks for including something of a reference to your previous comments. Please remember that in a long discussion, it's hard to keep every previous comment in mind, so it can be helpful to the readers if salient points made earlier are reiterated. While not required, of course, it can improve the discussion immensely.

Once you have results please do post them here. Specific information is always the best way to work out any issues, whether they are general or idiosyncratic.

To give you one hint; user interface hell!

A grid might have a primary currency (that the user holds a balance in), some regions on the grid may have a secondary currency such as Gloebit, and in addition you might have PayPal vendors (or other similar systems) offering in a third currency. Which currency do you display for the region? Which currency do you update the viewer primary interface to purchase in? Where do you display the balances the user might hold for the different curencies? You might also want to present the users with the transactions in the viewer as if to not have to log in to multiple websites to get an overview.

One of my takes is that both the object floater (that now) displays the currency the object is to be sold in, also must have functionality to be able to set the current and amount the object is to be sold in if there are multiple currencies on the grid.

Likewise the currency must displayed when the user clicks an object to make a purchase, and only then offers the user to purchase additional currency if they don't have the balance to proceed.

It is also imperative for the grid owner to have a view of monetary transactions going on on the grid, otherwise the grid owner has no idea if fraud, that he might be held accountable to by authorities, are ongoing on the grid.

By completely removing transactions from the grid owner's view (and this is also a concern with OMC), the grid owner is virtually blinded with the respect to the economy of the grid and fraudulence that might take place.

https://uploads.disquscdn.c...

Again, it appears you don't grasp how any of this works. There is no primary/secondary/multiple currency as far as the simulator is concerned.

For the primary currency (the grid currency) it must be enabled on Robust for the grid, and should be displayed as the primary balance and currency symbol on any region on that grid. I did not think any region could opt out of this by configuration unless you don't load the primary money module on the simulator, so it will always be there.

In general I would think a grid owner would like to have the primary grid currency enabled in every region for consistency on the grid.

In general I would think every merchant would like the merchandise or land to be able to sell in the primary grid currency.

Mr. Gloebit states further up "So, we didn't require that a grid switch completely to our module. It can be installed on a single sim. Further, it can be enabled only for specified regions running under that sim. If you don't want to run multiple currencies or don't want that functionality, that's fine."

This sounds like Gloebit can be installed in ADDITION to the grid currency in select regions, while it is not entirely clear if that removes the primary grid currency from the region.

Again, it appears you don't grasp how any of this works no matter how many times it has been explained to you. Instead of inferring and supposing and making assumptions on what you read in the comments section, you could read the simulator code or you could just at the very least take the people who have actually written money modules at their word.

This is Hypergrid Business, not Hypergrid Social. Questioning or commenting on the business decisions of a Grid is entirely within the scope of both the articles and comment sections under them.

Didn't get the idea from Zangrid's owner that she was down in any way but has mentioned in at least a couple places about how good her life is going to be leaving Opensim. So a little confused what you are on about with kicking her when she is down.

Of course you are confused about that. That is very clear from your comments on this post. Understanding that she was down would require empathy. Some people have it and some don't. So let me try and explain to you why I said the "kicking her when she is down" comment.....

Suz owns a grid and to most grid owners their grid is their baby. Closing a grid isn't an easy thing to do. Giving up that dream and all of the hard work they put in it isn't easy to do. So of course everyone involved is going to be down about it.

I understand that this isn't "Hypergrid Social". But OpenSim is suppose to be a family of sorts. It's a small community and if someone succeeds or fails it's up to the community to lift that person up not bring them down. I find that is rarely the case though. Instead people pile on with off topic comments like the one that included my name. I felt a need to nip that in the bud because it was just so outrageous.

As far as I can tell, her actual customers/land owners seem to be very understanding about things. I'm just not sure why some find it their place to be the negative voice in almost every comment on almost every post. But they do and then it normally spins out to replies and more comments until there are now 50 comments here and probably only a couple of them actually show any community spirit and empathy for their fellow OpenSim user.

And let me end this post by saying that I am not a Suz fan. I was on the outs with her. But that doesn't stop me from being human and understanding that this is probably a hard time for her and her team. It was a good grid. It was apparent that they (owners, admin, residents) put a lot of work into it. And even though I didn't get along with her well on a personal level I see that she is trying to exit this project gracefully and with class. She seems to be doing all of the right things in the way she informed her residents and by informing the OpenSim community.

And even after all of the negative comments here she still managed to stay upbeat and look forward and focus on her future and do it with class. A teachable moment for sure.

Hi Geir, thank you for providing me the opportunity to speak to this. I should attend more developer meetings.

I (for Gloebit and at the request of some customers) implemented land pass sales strictly in the Gloebit Money Module without any modification to the OpenSim Core. As I did so, I passed along all the research I did on the opensim-dev IRC channel. When core learned that I completed this, they did not want Gloebit to have an advantage and did not want the logic handled in the money module (and did not understand that much of the logic of all of the other transaction flows is handled in the money module, not in core), so they rushed a modification into the 0.9.1-dev specifically to pre-empt the work I had done. I begged them to stop and design this and explained they were making breaking changes. Core would not listen. I wish someone from OMC or anyone who has complained about this would have been in IRC when I was fighting this battle without much support. A couple of weeks later, core did something unprecedented, and pulled all of the 0.9.1-dev changes into the 0.9.0-release. I explained how this was bad process and how they specifically released a breaking change to the money module interface which was not in any release candidate and which no module was prepared for (including Gloebit). They didn't really seem to care.

Gloebit's money module was also broken at this point, and I had to rush out a fix for everyone on 0.9.0-release and 0.9.1-dev. I actually had to do more than twice as much work because of this modification to the core. The Gloebit Money Module has two implementations for land-pass sales: 1 which is handled entirely in the module for OpenSim prior to 0.9.0-release, and one which uses the new flow and interface which core added in 0.9.0-release and beyond.

Trust me, I (on behalf of Gloebit) was pushing against making any changes to core, not pushing for them. I also was not satisfied with the design decisions made for the new interface function. I did my best to guide them to improve it, but most of my suggestions were ignored. I also asked them to wait and get opinions other than mine from grids and other currency modules, to no avail.

Agreed Geir. I begged core to get input and not to rush money module changes.

Cinder, there doesn't need to be consensus, but APIs should be well thought out and ideally breaking changes should only be made when absolutely necessary. When possible, they should be phased in to give developers a chance to release versions that support the new interfaces before customers see crashes. This did not happen in this case.

Core very quickly implemented a flow to handle land pass sales under the believe that they had all the money module tools they needed. I informed them that they didn't and should take some time to plan this. No planning went into this (other than the research I had published in IRC as to how to capture the land-pass sale flow) before coding was started. They first tried to use the flows that uploading of textures or group creation fees uses. I had to inform them that those don't supply any information for who to pay (the land owner) or any details of the transaction (such as the parcel). They then jumped to using the existing MoveMoney() function, but I informed them that this flow might hand out a land pass when the payment failed as it returned void. They added a new interface function which returns a bool to resolve this. I asked that they add a dictionary arg to this so that information about the transaction could be passed to the money module and so that it might be more flexible for future transaction modifications, but they seemed set on preventing the money module from having access to any info beyond a string description. I asked that they provide a callback function for the money module to call after it had asynchronously completed the transaction (so that the money module could control delivery of the pass), but this was also refused and they went with a flow where the core fully controls the flow.

This could have been done without breaking any money modules by creating a new event in core which the money module could subscribe to. For modules which didn't, this event would be fired and nothing would happen. My other suggestion was that if they add a new interface function, they do it now and announce that they would start using it some number of versions in the future, to give all money modules a chance to implement it. Instead, they added it and immediately began using it.

Further, these changes were made in the 0.9.1-dev branch and really should never have impacted the 0.9.0-release. So, even if you are making breaking changes, those should not end up in a release if they weren't in the release candidates for a version. Sure, core has the ability to do what they want and sometimes moving quickly is the right move. I don't believe they needed to move this quickly here and I believe a lot of bad decisions were made which unnecessarily adversely affected customers.

Thanks Cinder. We're working out butts off.

Right, as the maintainer for a software library, I understand the need for API/ABI stability if you expect any consumers of the library to make effective use of it, but I have a special loathing for the majority of OpenSim money modules, their memory leaks, and their home-brewed security schemes, and will happily see the unmaintained ones obsoleted by improvements.

Some more clarification:

1. Does OpenSim version 0.9.1 have changes that break some money modules? -- yes, AND those changes are not related to this patch. They broke the Gloebit Money Module as well, and I had to patch it. Those changes are actually also in 0.9.0-release. They are related to land-pass sales and neither I nor Gloebit asked for those changes. I asked core not to make those changes without inviting a lot of discussion and design first and I asked them to delay rolling them out once they were made so that money module developers would have a chance to patch their modules. Sorry, I lost all of those battles.

2. Shouldn't you have fixed this by allowing a user to choose which currency to use when they are making a purchase? - NO. The goal here was to make a reasonably quick fix that would not break anything (like other money modules), not to completely redesign OpenSim. I'd love it if people worked with us to vastly improve OpenSim transactions and eventually implement a new system, but that would take a very long time, break every existing money module, require viewer and core devs to agree upon an interface, and it would likely break compatibility of those viewers with SL. This fix causes none of those problems and improves the functionality.

3. Finally, let me briefly explain how transactions and currency work in OpenSim. By default, OpenSim doesn't handle any transactions. The included default money module doesn't really do anything. It is just a reference. At the grid level, you can set the currency symbol across the grid and you can set the helper-uri. The helper-uri is where api calls are made when a user attempts to purchase land or purchase currency. I won't get into why these historically have been outside of the money module. When you attempt to buy an object, pay a user, pay an object, pay to upload a texture, pay to buy a land pass, pay to create a group, etc., these api calls are handled by a money module. There is no grid wide money module. The money module is a region module. What that means is that these calls are handled by the sim or region you are on when you make the request, not by the grid. For grids with a single currency across the grid, they have the same money module installed on every sim across the grid. In cases of grids which allow users to purchase in multiple currencies, users do not choose the currency at the time of purchase. For all built in UI transaction methods, there is a single currency per region. To use a different currency, a user would have to go to a region which has a different currency module enabled, and on that region, all built in transactions would happen in that currency. The other option is to use scripted vendors. These vendors don't use the built in interfaces. They can call their own external APIs directly (for instance on some web server). They can allow a user to choose the currency to use and they can use a currency which is not the same as the money module for that sim. But, they don't work via the built-in UI or via paying the vending machine directly. Finally, it's not simple to just start allowing a user to choose which currency to use when making a purchase. First, the seller would need to have set the price in every currency they are willing to sell in. The seller would need a new viewer interface for setting their items to sale, a new communication protocol with the server to carry this information, and the server would need to modify or create a new db table to store this additional information. These prices would need to be presented to users so there would need to be more communication and UI changes to get this information back to a purchaser. The viewer would need to implement UI to choose the currency and a new communication protocol to send the currency choice to the server. The money modules would need to be completely redesigned to handle this as multiple would need to be enabled per region or they would need to be turned into robust services. This is just what I can think of off of the top of my head. I'm sure there would be more. It's nice to say "this is how it should be done", but it's not that easy. It doesn't mean we can't shoot for that in the long run, but we shouldn't discourage incremental improvements in the meantime, and anyone suggesting that there is a better way to improve the system should be asked to specify how and how long it would take.

This is probably how the perception of changes made for Gloebit came up, as you (apparently) where the only person interacting with the devs while making the land pass changes, and they did, as you describe above, "make changes to make it work with your currency module".

It sounds from the above, that despite making interim changes, at the end of the day they went ahead and did their own thing breaking a lot of eggs as a result.

You took credit for my videos?

There has always been copybotting and imported stolen content in SL.

New life? If you enjoy SL then I hope it will.

What video’s?