Re: [Opensim-dev] User services refactoring status
On Fri, Jan 8, 2010 at 10:16 PM, d...@metaverseink.com wrote: It's there, but it's scattered and incomplete, as everything else. One of us will have to start this effort, but there is no way that core devs alone will be able to put the bulk of the documentation together. We can, for example, start with the Table of Contents, write the introductory parts, but then some volunteers will have to step up and I think this is definitely a start, and better than nothing. I know myself, the way I teach myself a code base sometimes is to start documenting it. Moreover I find it in line with an open source project that people build a skeleton for collaborative fleshing-in. Please do go ahead with creating the skeleton as soon you have the time, as this helps out down-stream projects like reX quite immensely in planning and organizing their work. What I'd like to see: 1. TOC 2. Introductions to each chapter 3. A sentence or two with what you want to say, and links to the relevant code 4. A couple paragraphs more for the bigger bits, like the meaning behind the Interfaces, or how robust works Basically enough of a seed to let other people come in and flesh out and grow the documentation. If it's just an empty place-holder, there's no purchase for the thing to grow. Cheers, start figuring out what to write in there. Speaking for myself, I have no time for both coding/testing and heavy-duty documentation. It's not that I don't think documentation is not important -- it is -- it's just lack of time. Writing good documentation takes as much time as writing code. If someone here really wants to help the project, doesn't code but writes English well... consider volunteering as a documenter! -- it's fun, you get to try OpenSim in all sorts of modes, so that you know how it works and what to write, and you also get to pick on core devs' brains. I know for a fact that many of you here are already advanced enough in OpenSim configuration and testing that you could do this very effectively... Anyway, if I had a say in it, my preference would be to do the bulk of the documentation effort between 0.7 and 1.0. After 0.7 gets tagged, and if no one beats me to it, I'll do a draft of the TOC, and then ppl will have a better idea of what's needed. (FYI, here are the pieces currently about ROBUST, but this needs to be revised, anyway. http://opensimulator.org/wiki/OpenSim_Services_and_Service_Connectors http://opensimulator.org/wiki/ROBUST ) Fly Man wrote: Diva, That was a discussion that has been done on the #opensim-dev channel and so far, I haven't seen a single documentation point entrusted to the Wiki about the new ROBUST components Maybe it's a good idea for you to lead the way ? 2010/1/8 d...@metaverseink.com mailto:d...@metaverseink.com Impalah Shenzhou wrote: There is only one thing I really miss for making this: the interfaces between simultator-UGAIM are not clearly documented and we have to navigate into code to konow what we have to do. I have pointed to the code, because that's all there is at the moment, and it's not even finished. That is not to say that that's all there ever will be. Documentation is in the near future, at least for me, as something that will be increasingly important for the project, critical even. I'm not sure core devs can do it alone, though -- in fact, I'm pretty sure we can't. I think we need to organize this community of users-developers much better than we have been doing before to produce The OpenSim Guide. It can't be a free-for-all, anarchic, design-free wiki like we have been having so far (this is my opinion only, and doesn't represent any official position of the core devs, but I'm sticking to it). We need leaders (i.e. Wikipedia admins). Personally I would love to see the emergence of a group of people here who would become the core documenters. Those people would work very closely with core devs in order to extract the knowledge out of our heads and into documentation. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de mailto:Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] User services refactoring status
.NET is ok and I appreciate why it was used for OpenSim, but most of the CMS systems that I have come across and may want to integrate are not .NET such as Joomla, Drupal. Would this mean installing Mono on all systems, not just the OpenSim systems? Still a helpful alternative to consider. On 7 Jan 2010, at 20:39, Impalah Shenzhou wrote: If someone is looking for some kind of purity (using exclusively .NET for web management) recently I have discovered http://www.dotnetnuke.com/ Is a CMS (like Alfresco, Drupal, Joomla...) but runs over .NET. It shouldn't be too difficult to connect the native Opensim components to get/set data instead of accessing directly to database. Greetings 2010/1/7 Fly Man fly.man.open...@gmail.com In other words: Wiredux won't use those connectors but will grab to the database itself. Wiredux is not a .NET application so it will go directly to the database. I will wait until the refactoring is done, have a look what's wrecked and maybe fix it. 2010/1/5 d...@metaverseink.com Putting PHP in front of the DBs is one of the most natural things to do from here on -- not just the things that Wiredux does, but for a lot more! In fact, the entire collection of OpenSim.Services that are provided as reference implementations can be replaced with implementations in Apache+PHP. Calls from the simulators to the services are now all neatly packaged in OpenSim.Services.Connectors (these are the out connectors). Just browse through those connectors and check out the wire protocols, then do the receiving end in PHP. Many of them are using standard web forms, others use XMLRPC, others use custom-made HTTP-based dialects. Calls from outside to the simulators are packaged in OpenSim.Server.Handlers. Again, check them out and, if not using .NET, write your own client for them. If using .NET/mono you can import the DLL OpenSim.Connectors.dll, and reuse the existing connectors as-is. But that's not all. Since now the interactions between the simulators and the resource services are all formalized in interfaces (OpenSim.Services.Interfaces), and the handlers and connectors in the simulator are loaded dynamically, you can replace the connectors and handlers themselves. In other words, if you want OpenSim to talk web services, roll your own Web Services handlers and connectors under those interfaces, and you're done -- you'll have to use .NET for this part, though. Tom Willans wrote: Hi, First thanks for all your work. I assume from this that the webredux will no longer work without modification and will need updating. ( Thanks again here). Is there any information about the new authentication approach anywhere, if not in detail then an overview. Is LDAP on the horizon? I am mostly interested in linking php based frontends to opensim and hence accessing the database directly. Particularly relevant is moving away from using UUIDs. Please forgive me if I am missing something but I assume there are no web-services that can be called and calling C# from php is not a very good solution. Thanks. Tom On 5 Jan 2010, at 10:37, Ai Austin wrote: At 18:32 04/01/2010, opensim-dev-requ...@lists.berlios.de mailto:opensim-dev-requ...@lists.berlios.de wrote: To be honest, I don't think Sqlite should be a database type that we (OpenSim) should keep alive in the project, It is useful to have a double click and go out of the box solution which people can try out and test with. One other use of SQLite that I am aware of and fine very useful is for the really simple and handy single region hosted on your own system that is connected to the New World Grid for any avatar using the New World Studio packaged version of Opensim. See http://www.newworldgrid.com/lang/en-us/land/free-land ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de mailto:Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev Tom Willans Managing Director Bessacarr Publications Ltd 3 Highfield, Hatton Park, Warwick, CV35 7TQ tom.will...@bessacarr.com mailto:tom.will...@bessacarr.com +44 (0) 1926 402055 +44 (0) 121 288 0281 Registered in England and Wales at the above address. Company No: 4925067. VAT No:GB 823 9317 24. This e-mail is confidential and intended solely for the use of the individual to whom it is addressed. Any views or opinions presented are solely those of the author and do not necessarily represent those of Bessacarr Publications Ltd. If you are not the intended recipient you have received this e-mail in error and that any use, dissemination, forwarding, printing or copying of this e-mail is strictly prohibited. Please return it to the sender immediately. The contents of this message may be legally privileged.
Re: [Opensim-dev] User services refactoring status
This would be very helpful. Thxs On 7 Jan 2010, at 20:25, Fly Man wrote: In other words: Wiredux won't use those connectors but will grab to the database itself. Wiredux is not a .NET application so it will go directly to the database. I will wait until the refactoring is done, have a look what's wrecked and maybe fix it. 2010/1/5 d...@metaverseink.com Putting PHP in front of the DBs is one of the most natural things to do from here on -- not just the things that Wiredux does, but for a lot more! In fact, the entire collection of OpenSim.Services that are provided as reference implementations can be replaced with implementations in Apache+PHP. Calls from the simulators to the services are now all neatly packaged in OpenSim.Services.Connectors (these are the out connectors). Just browse through those connectors and check out the wire protocols, then do the receiving end in PHP. Many of them are using standard web forms, others use XMLRPC, others use custom-made HTTP-based dialects. Calls from outside to the simulators are packaged in OpenSim.Server.Handlers. Again, check them out and, if not using .NET, write your own client for them. If using .NET/mono you can import the DLL OpenSim.Connectors.dll, and reuse the existing connectors as-is. But that's not all. Since now the interactions between the simulators and the resource services are all formalized in interfaces (OpenSim.Services.Interfaces), and the handlers and connectors in the simulator are loaded dynamically, you can replace the connectors and handlers themselves. In other words, if you want OpenSim to talk web services, roll your own Web Services handlers and connectors under those interfaces, and you're done -- you'll have to use .NET for this part, though. Tom Willans wrote: Hi, First thanks for all your work. I assume from this that the webredux will no longer work without modification and will need updating. ( Thanks again here). Is there any information about the new authentication approach anywhere, if not in detail then an overview. Is LDAP on the horizon? I am mostly interested in linking php based frontends to opensim and hence accessing the database directly. Particularly relevant is moving away from using UUIDs. Please forgive me if I am missing something but I assume there are no web-services that can be called and calling C# from php is not a very good solution. Thanks. Tom On 5 Jan 2010, at 10:37, Ai Austin wrote: At 18:32 04/01/2010, opensim-dev-requ...@lists.berlios.de mailto:opensim-dev-requ...@lists.berlios.de wrote: To be honest, I don't think Sqlite should be a database type that we (OpenSim) should keep alive in the project, It is useful to have a double click and go out of the box solution which people can try out and test with. One other use of SQLite that I am aware of and fine very useful is for the really simple and handy single region hosted on your own system that is connected to the New World Grid for any avatar using the New World Studio packaged version of Opensim. See http://www.newworldgrid.com/lang/en-us/land/free-land ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de mailto:Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev Tom Willans Managing Director Bessacarr Publications Ltd 3 Highfield, Hatton Park, Warwick, CV35 7TQ tom.will...@bessacarr.com mailto:tom.will...@bessacarr.com +44 (0) 1926 402055 +44 (0) 121 288 0281 Registered in England and Wales at the above address. Company No: 4925067. VAT No:GB 823 9317 24. This e-mail is confidential and intended solely for the use of the individual to whom it is addressed. Any views or opinions presented are solely those of the author and do not necessarily represent those of Bessacarr Publications Ltd. If you are not the intended recipient you have received this e-mail in error and that any use, dissemination, forwarding, printing or copying of this e-mail is strictly prohibited. Please return it to the sender immediately. The contents of this message may be legally privileged. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev Tom Willans Managing Director Bessacarr Publications Ltd 3 Highfield, Hatton Park, Warwick, CV35 7TQ tom.will...@bessacarr.com +44 (0) 1926 402055 +44 (0) 121 288 0281 Registered in England and Wales at the above address. Company No: 4925067.
Re: [Opensim-dev] User services refactoring status
UGAIM servers are simply a bunch of http services (xml-rpc and REST) so is not too difficult to move them to any standard CMS. Dotnetnuke is only a pure .NET alternative that will allow to use the existing components natively without rewriting all the internal code. You could have both a complete CMS and the UGAIM servers. It's one of the many ways to make a comfortable environment for administrators/users. But... personally I don't like aspx, IIS and all the related .NET stuff for serving http. For me it's too heavy (not as heavy loaded as Java, but heavy anyway). So... Buried in the forge there was, some time ago, a Perl implementation of UGAIM and worked quite well (with its limitations). I tried myself to implement ugaim as Drupal modules, but the performance was horrible compared with existing UGAIM... so I tried another frameworks. Actually I have a complete UGAIM implementation using the high performance Code Igniter PHP framework. With its backend, it's AJAXified windows, its scalability given by Apache and all that kind of funny things. That's what I did, but I understand that Opensim Core shouldn't cover that kind of stuff. Existing UGAIM/ROBUST are implementation examples and cover the basic needs of the opensim simulator. Python/Ironpython is another alternative, using Django, TornadoWeb, Twister, or even Zope. Java could be an alternative too (not for me, I hate Java after years of pain with it). What I am trying to say is that there are as many alternative as people on the lists. Opensim provides us with one basic alternative (ugaim/robust) and if we don't like it... well, we are free to create ours. There is only one thing I really miss for making this: the interfaces between simultator-UGAIM are not clearly documented and we have to navigate into code to konow what we have to do. That's my opinion but if you don't like, I have more. 2010/1/8 Tom Willans tom.will...@bessacarr.com .NET is ok and I appreciate why it was used for OpenSim, but most of the CMS systems that I have come across and may want to integrate are not .NET such as Joomla, Drupal. Would this mean installing Mono on all systems, not just the OpenSim systems? Still a helpful alternative to consider. On 7 Jan 2010, at 20:39, Impalah Shenzhou wrote: If someone is looking for some kind of purity (using exclusively .NET for web management) recently I have discovered http://www.dotnetnuke.com/ Is a CMS (like Alfresco, Drupal, Joomla...) but runs over .NET. It shouldn't be too difficult to connect the native Opensim components to get/set data instead of accessing directly to database. Greetings 2010/1/7 Fly Man fly.man.open...@gmail.com In other words: Wiredux won't use those connectors but will grab to the database itself. Wiredux is not a .NET application so it will go directly to the database. I will wait until the refactoring is done, have a look what's wrecked and maybe fix it. 2010/1/5 d...@metaverseink.com Putting PHP in front of the DBs is one of the most natural things to do from here on -- not just the things that Wiredux does, but for a lot more! In fact, the entire collection of OpenSim.Services that are provided as reference implementations can be replaced with implementations in Apache+PHP. Calls from the simulators to the services are now all neatly packaged in OpenSim.Services.Connectors (these are the out connectors). Just browse through those connectors and check out the wire protocols, then do the receiving end in PHP. Many of them are using standard web forms, others use XMLRPC, others use custom-made HTTP-based dialects. Calls from outside to the simulators are packaged in OpenSim.Server.Handlers. Again, check them out and, if not using .NET, write your own client for them. If using .NET/mono you can import the DLL OpenSim.Connectors.dll, and reuse the existing connectors as-is. But that's not all. Since now the interactions between the simulators and the resource services are all formalized in interfaces (OpenSim.Services.Interfaces), and the handlers and connectors in the simulator are loaded dynamically, you can replace the connectors and handlers themselves. In other words, if you want OpenSim to talk web services, roll your own Web Services handlers and connectors under those interfaces, and you're done -- you'll have to use .NET for this part, though. Tom Willans wrote: Hi, First thanks for all your work. I assume from this that the webredux will no longer work without modification and will need updating. ( Thanks again here). Is there any information about the new authentication approach anywhere, if not in detail then an overview. Is LDAP on the horizon? I am mostly interested in linking php based frontends to opensim and hence accessing the database directly. Particularly relevant is moving away from using UUIDs. Please forgive me if I am missing something but I assume there are no web-services that
Re: [Opensim-dev] User services refactoring status
Impalah Shenzhou wrote: There is only one thing I really miss for making this: the interfaces between simultator-UGAIM are not clearly documented and we have to navigate into code to konow what we have to do. I have pointed to the code, because that's all there is at the moment, and it's not even finished. That is not to say that that's all there ever will be. Documentation is in the near future, at least for me, as something that will be increasingly important for the project, critical even. I'm not sure core devs can do it alone, though -- in fact, I'm pretty sure we can't. I think we need to organize this community of users-developers much better than we have been doing before to produce The OpenSim Guide. It can't be a free-for-all, anarchic, design-free wiki like we have been having so far (this is my opinion only, and doesn't represent any official position of the core devs, but I'm sticking to it). We need leaders (i.e. Wikipedia admins). Personally I would love to see the emergence of a group of people here who would become the core documenters. Those people would work very closely with core devs in order to extract the knowledge out of our heads and into documentation. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] User services refactoring status
Diva, That was a discussion that has been done on the #opensim-dev channel and so far, I haven't seen a single documentation point entrusted to the Wiki about the new ROBUST components Maybe it's a good idea for you to lead the way ? 2010/1/8 d...@metaverseink.com Impalah Shenzhou wrote: There is only one thing I really miss for making this: the interfaces between simultator-UGAIM are not clearly documented and we have to navigate into code to konow what we have to do. I have pointed to the code, because that's all there is at the moment, and it's not even finished. That is not to say that that's all there ever will be. Documentation is in the near future, at least for me, as something that will be increasingly important for the project, critical even. I'm not sure core devs can do it alone, though -- in fact, I'm pretty sure we can't. I think we need to organize this community of users-developers much better than we have been doing before to produce The OpenSim Guide. It can't be a free-for-all, anarchic, design-free wiki like we have been having so far (this is my opinion only, and doesn't represent any official position of the core devs, but I'm sticking to it). We need leaders (i.e. Wikipedia admins). Personally I would love to see the emergence of a group of people here who would become the core documenters. Those people would work very closely with core devs in order to extract the knowledge out of our heads and into documentation. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] User services refactoring status
It's there, but it's scattered and incomplete, as everything else. One of us will have to start this effort, but there is no way that core devs alone will be able to put the bulk of the documentation together. We can, for example, start with the Table of Contents, write the introductory parts, but then some volunteers will have to step up and start figuring out what to write in there. Speaking for myself, I have no time for both coding/testing and heavy-duty documentation. It's not that I don't think documentation is not important -- it is -- it's just lack of time. Writing good documentation takes as much time as writing code. If someone here really wants to help the project, doesn't code but writes English well... consider volunteering as a documenter! -- it's fun, you get to try OpenSim in all sorts of modes, so that you know how it works and what to write, and you also get to pick on core devs' brains. I know for a fact that many of you here are already advanced enough in OpenSim configuration and testing that you could do this very effectively... Anyway, if I had a say in it, my preference would be to do the bulk of the documentation effort between 0.7 and 1.0. After 0.7 gets tagged, and if no one beats me to it, I'll do a draft of the TOC, and then ppl will have a better idea of what's needed. (FYI, here are the pieces currently about ROBUST, but this needs to be revised, anyway. http://opensimulator.org/wiki/OpenSim_Services_and_Service_Connectors http://opensimulator.org/wiki/ROBUST ) Fly Man wrote: Diva, That was a discussion that has been done on the #opensim-dev channel and so far, I haven't seen a single documentation point entrusted to the Wiki about the new ROBUST components Maybe it's a good idea for you to lead the way ? 2010/1/8 d...@metaverseink.com mailto:d...@metaverseink.com Impalah Shenzhou wrote: There is only one thing I really miss for making this: the interfaces between simultator-UGAIM are not clearly documented and we have to navigate into code to konow what we have to do. I have pointed to the code, because that's all there is at the moment, and it's not even finished. That is not to say that that's all there ever will be. Documentation is in the near future, at least for me, as something that will be increasingly important for the project, critical even. I'm not sure core devs can do it alone, though -- in fact, I'm pretty sure we can't. I think we need to organize this community of users-developers much better than we have been doing before to produce The OpenSim Guide. It can't be a free-for-all, anarchic, design-free wiki like we have been having so far (this is my opinion only, and doesn't represent any official position of the core devs, but I'm sticking to it). We need leaders (i.e. Wikipedia admins). Personally I would love to see the emergence of a group of people here who would become the core documenters. Those people would work very closely with core devs in order to extract the knowledge out of our heads and into documentation. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de mailto:Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] User services refactoring status
d...@metaverseink.com wrote: It's there, but it's scattered and incomplete, as everything else. One of us will have to start this effort, but there is no way that core devs alone will be able to put the bulk of the documentation together. We can, for example, start with the Table of Contents, write the introductory parts, but then some volunteers will have to step up and start figuring out what to write in there. Speaking for myself, I have no time for both coding/testing and heavy-duty documentation. It's not that I don't think documentation is not important -- it is -- it's just lack of time. Writing good documentation takes as much time as writing code. If someone here really wants to help the project, doesn't code but writes English well... consider volunteering as a documenter! -- it's fun, you get to try OpenSim in all sorts of modes, so that you know how it works and what to write, and you also get to pick on core devs' brains. I know for a fact that many of you here are already advanced enough in OpenSim configuration and testing that you could do this very effectively... Anyway, if I had a say in it, my preference would be to do the bulk of the documentation effort between 0.7 and 1.0. After 0.7 gets tagged, and if no one beats me to it, I'll do a draft of the TOC, and then ppl will have a better idea of what's needed. I think a TOC will help but it's probably not enough. I think people will need more of an outline if this approach is going to work. It could be pretty minimal but it needs to be enough to give people a fighting chance. We've already seen the result of the minimalist, unstructured approach in the wiki. And to be honest, I feel that not explaining code is already creating a situation where only people with buckets of time or a high level of experience will attempt to interact with OpenSim on the code level. Writing good documentation is just as much a part of a good programmer's role as writing the code itself. (FYI, here are the pieces currently about ROBUST, but this needs to be revised, anyway. http://opensimulator.org/wiki/OpenSim_Services_and_Service_Connectors http://opensimulator.org/wiki/ROBUST ) Fly Man wrote: Diva, That was a discussion that has been done on the #opensim-dev channel and so far, I haven't seen a single documentation point entrusted to the Wiki about the new ROBUST components Maybe it's a good idea for you to lead the way ? 2010/1/8 d...@metaverseink.com mailto:d...@metaverseink.com Impalah Shenzhou wrote: There is only one thing I really miss for making this: the interfaces between simultator-UGAIM are not clearly documented and we have to navigate into code to konow what we have to do. I have pointed to the code, because that's all there is at the moment, and it's not even finished. That is not to say that that's all there ever will be. Documentation is in the near future, at least for me, as something that will be increasingly important for the project, critical even. I'm not sure core devs can do it alone, though -- in fact, I'm pretty sure we can't. I think we need to organize this community of users-developers much better than we have been doing before to produce The OpenSim Guide. It can't be a free-for-all, anarchic, design-free wiki like we have been having so far (this is my opinion only, and doesn't represent any official position of the core devs, but I'm sticking to it). We need leaders (i.e. Wikipedia admins). Personally I would love to see the emergence of a group of people here who would become the core documenters. Those people would work very closely with core devs in order to extract the knowledge out of our heads and into documentation. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de mailto:Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev -- Justin Clark-Casey (justincc) http://justincc.org http://twitter.com/justincc ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] User services refactoring status
On Jan 8, 2010, at 1:46 PM, Justin Clark-Casey wrote: Writing good documentation is just as much a part of a good programmer's role as writing the code itself. Documentation is superlinear with the code. Good documentation is not just a collection of disconnected articles covering the different parts of the system -- i.e. bottom-up. That's what happened so far, and the results show. Good documentation requires a top-down approach, i.e. someone needs to think about the TOC, set the tone for the document (extremely important!), and make sure language is consistent all over the place. Then the different parts can be filled up. Without this planning and continuous supervision of the document, the independent documentation efforts of the parts are bound to be a disaster as a whole, and highly ineffective in isolation (because nothing is ever isolated). (Academic interjection: that's one of the main reasons why documentation is at odds with early-stage development that follows agile practices, especially in projects where there is no single point of control. One is top-down, the other is bottom-up.) There's no question that the only people who can write the TOC, and set the tone, are the core devs plus 4 or 5 other people who are very familiar with OpenSim. But I think that there is a larger number of people who can fill in the parts -- as we can see from the wiki -- except that we haven't been guiding them well, because... we haven't been guiding anything so far, things were too much in flux. I think we're reaching a point where this kind of coordinated effort can occur. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] User services refactoring status
In other words: Wiredux won't use those connectors but will grab to the database itself. Wiredux is not a .NET application so it will go directly to the database. I will wait until the refactoring is done, have a look what's wrecked and maybe fix it. 2010/1/5 d...@metaverseink.com Putting PHP in front of the DBs is one of the most natural things to do from here on -- not just the things that Wiredux does, but for a lot more! In fact, the entire collection of OpenSim.Services that are provided as reference implementations can be replaced with implementations in Apache+PHP. Calls from the simulators to the services are now all neatly packaged in OpenSim.Services.Connectors (these are the out connectors). Just browse through those connectors and check out the wire protocols, then do the receiving end in PHP. Many of them are using standard web forms, others use XMLRPC, others use custom-made HTTP-based dialects. Calls from outside to the simulators are packaged in OpenSim.Server.Handlers. Again, check them out and, if not using .NET, write your own client for them. If using .NET/mono you can import the DLL OpenSim.Connectors.dll, and reuse the existing connectors as-is. But that's not all. Since now the interactions between the simulators and the resource services are all formalized in interfaces (OpenSim.Services.Interfaces), and the handlers and connectors in the simulator are loaded dynamically, you can replace the connectors and handlers themselves. In other words, if you want OpenSim to talk web services, roll your own Web Services handlers and connectors under those interfaces, and you're done -- you'll have to use .NET for this part, though. Tom Willans wrote: Hi, First thanks for all your work. I assume from this that the webredux will no longer work without modification and will need updating. ( Thanks again here). Is there any information about the new authentication approach anywhere, if not in detail then an overview. Is LDAP on the horizon? I am mostly interested in linking php based frontends to opensim and hence accessing the database directly. Particularly relevant is moving away from using UUIDs. Please forgive me if I am missing something but I assume there are no web-services that can be called and calling C# from php is not a very good solution. Thanks. Tom On 5 Jan 2010, at 10:37, Ai Austin wrote: At 18:32 04/01/2010, opensim-dev-requ...@lists.berlios.de mailto:opensim-dev-requ...@lists.berlios.de wrote: To be honest, I don't think Sqlite should be a database type that we (OpenSim) should keep alive in the project, It is useful to have a double click and go out of the box solution which people can try out and test with. One other use of SQLite that I am aware of and fine very useful is for the really simple and handy single region hosted on your own system that is connected to the New World Grid for any avatar using the New World Studio packaged version of Opensim. See http://www.newworldgrid.com/lang/en-us/land/free-land ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de mailto:Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev Tom Willans Managing Director Bessacarr Publications Ltd 3 Highfield, Hatton Park, Warwick, CV35 7TQ tom.will...@bessacarr.com mailto:tom.will...@bessacarr.com +44 (0) 1926 402055 +44 (0) 121 288 0281 Registered in England and Wales at the above address. Company No: 4925067. VAT No:GB 823 9317 24. This e-mail is confidential and intended solely for the use of the individual to whom it is addressed. Any views or opinions presented are solely those of the author and do not necessarily represent those of Bessacarr Publications Ltd. If you are not the intended recipient you have received this e-mail in error and that any use, dissemination, forwarding, printing or copying of this e-mail is strictly prohibited. Please return it to the sender immediately. The contents of this message may be legally privileged. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] User services refactoring status
If someone is looking for some kind of purity (using exclusively .NET for web management) recently I have discovered http://www.dotnetnuke.com/ Is a CMS (like Alfresco, Drupal, Joomla...) but runs over .NET. It shouldn't be too difficult to connect the native Opensim components to get/set data instead of accessing directly to database. Greetings 2010/1/7 Fly Man fly.man.open...@gmail.com In other words: Wiredux won't use those connectors but will grab to the database itself. Wiredux is not a .NET application so it will go directly to the database. I will wait until the refactoring is done, have a look what's wrecked and maybe fix it. 2010/1/5 d...@metaverseink.com Putting PHP in front of the DBs is one of the most natural things to do from here on -- not just the things that Wiredux does, but for a lot more! In fact, the entire collection of OpenSim.Services that are provided as reference implementations can be replaced with implementations in Apache+PHP. Calls from the simulators to the services are now all neatly packaged in OpenSim.Services.Connectors (these are the out connectors). Just browse through those connectors and check out the wire protocols, then do the receiving end in PHP. Many of them are using standard web forms, others use XMLRPC, others use custom-made HTTP-based dialects. Calls from outside to the simulators are packaged in OpenSim.Server.Handlers. Again, check them out and, if not using .NET, write your own client for them. If using .NET/mono you can import the DLL OpenSim.Connectors.dll, and reuse the existing connectors as-is. But that's not all. Since now the interactions between the simulators and the resource services are all formalized in interfaces (OpenSim.Services.Interfaces), and the handlers and connectors in the simulator are loaded dynamically, you can replace the connectors and handlers themselves. In other words, if you want OpenSim to talk web services, roll your own Web Services handlers and connectors under those interfaces, and you're done -- you'll have to use .NET for this part, though. Tom Willans wrote: Hi, First thanks for all your work. I assume from this that the webredux will no longer work without modification and will need updating. ( Thanks again here). Is there any information about the new authentication approach anywhere, if not in detail then an overview. Is LDAP on the horizon? I am mostly interested in linking php based frontends to opensim and hence accessing the database directly. Particularly relevant is moving away from using UUIDs. Please forgive me if I am missing something but I assume there are no web-services that can be called and calling C# from php is not a very good solution. Thanks. Tom On 5 Jan 2010, at 10:37, Ai Austin wrote: At 18:32 04/01/2010, opensim-dev-requ...@lists.berlios.de mailto:opensim-dev-requ...@lists.berlios.de wrote: To be honest, I don't think Sqlite should be a database type that we (OpenSim) should keep alive in the project, It is useful to have a double click and go out of the box solution which people can try out and test with. One other use of SQLite that I am aware of and fine very useful is for the really simple and handy single region hosted on your own system that is connected to the New World Grid for any avatar using the New World Studio packaged version of Opensim. See http://www.newworldgrid.com/lang/en-us/land/free-land ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de mailto:Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev Tom Willans Managing Director Bessacarr Publications Ltd 3 Highfield, Hatton Park, Warwick, CV35 7TQ tom.will...@bessacarr.com mailto:tom.will...@bessacarr.com +44 (0) 1926 402055 +44 (0) 121 288 0281 Registered in England and Wales at the above address. Company No: 4925067. VAT No:GB 823 9317 24. This e-mail is confidential and intended solely for the use of the individual to whom it is addressed. Any views or opinions presented are solely those of the author and do not necessarily represent those of Bessacarr Publications Ltd. If you are not the intended recipient you have received this e-mail in error and that any use, dissemination, forwarding, printing or copying of this e-mail is strictly prohibited. Please return it to the sender immediately. The contents of this message may be legally privileged. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] User services refactoring status
Impalah Shenzhou kirjoitti: http://www.dotnetnuke.com/ Is a CMS (like Alfresco, Drupal, Joomla...) but runs over .NET. It shouldn't be too difficult to connect the native Opensim components to get/set data instead of accessing directly to database. It is also possible to use some of the Python written CMSes and web frameworks (Django and such) and the Opensim .net code together. I'd do it with pythondotnet, which is a .net to Python bridge for the normal cpython that allows use of .net libs in py apps. I've used that to use LibOMV in Blender before - it runs the normal .net vm under the hood and just translates the types passed/returned in the method calls, performance has seemed ok and would certainly be fine for the management stuff I can imagine. Another option would be IronPython, some folks have tried running Django on it: http://jdhardy.blogspot.com/2008/12/django-ironpython.html but afaik that is still incomplete - probably some simpler web frameworks work fully on it already. To me using the opensim code instead of direct access to DB seems attractive, given that the schemas may change, and that it's easy to make a mess if have bugs in own code that work with the db differently than Opensim itself? ~Toni 2010/1/7 Fly Man fly.man.open...@gmail.com mailto:fly.man.open...@gmail.com In other words: Wiredux won't use those connectors but will grab to the database itself. Wiredux is not a .NET application so it will go directly to the database. I will wait until the refactoring is done, have a look what's wrecked and maybe fix it. 2010/1/5 d...@metaverseink.com mailto:d...@metaverseink.com Putting PHP in front of the DBs is one of the most natural things to do from here on -- not just the things that Wiredux does, but for a lot more! In fact, the entire collection of OpenSim.Services that are provided as reference implementations can be replaced with implementations in Apache+PHP. Calls from the simulators to the services are now all neatly packaged in OpenSim.Services.Connectors (these are the out connectors). Just browse through those connectors and check out the wire protocols, then do the receiving end in PHP. Many of them are using standard web forms, others use XMLRPC, others use custom-made HTTP-based dialects. Calls from outside to the simulators are packaged in OpenSim.Server.Handlers. Again, check them out and, if not using .NET, write your own client for them. If using .NET/mono you can import the DLL OpenSim.Connectors.dll, and reuse the existing connectors as-is. But that's not all. Since now the interactions between the simulators and the resource services are all formalized in interfaces (OpenSim.Services.Interfaces), and the handlers and connectors in the simulator are loaded dynamically, you can replace the connectors and handlers themselves. In other words, if you want OpenSim to talk web services, roll your own Web Services handlers and connectors under those interfaces, and you're done -- you'll have to use .NET for this part, though. Tom Willans wrote: Hi, First thanks for all your work. I assume from this that the webredux will no longer work without modification and will need updating. ( Thanks again here). Is there any information about the new authentication approach anywhere, if not in detail then an overview. Is LDAP on the horizon? I am mostly interested in linking php based frontends to opensim and hence accessing the database directly. Particularly relevant is moving away from using UUIDs. Please forgive me if I am missing something but I assume there are no web-services that can be called and calling C# from php is not a very good solution. Thanks. Tom On 5 Jan 2010, at 10:37, Ai Austin wrote: At 18:32 04/01/2010, opensim-dev-requ...@lists.berlios.de mailto:opensim-dev-requ...@lists.berlios.de mailto:opensim-dev-requ...@lists.berlios.de mailto:opensim-dev-requ...@lists.berlios.de wrote: To be honest, I don't think Sqlite should be a database type that we (OpenSim) should keep alive in the project, It is useful to have a double click and go out of the box solution which people can try out and test with. One other use of SQLite that I am aware of and fine very useful is for the really
Re: [Opensim-dev] User services refactoring status
On 04/01/2010 9:02 AM, d...@metaverseink.com wrote: Unless someone steps in and takes care of the SQLite connector, I'm afraid it will go the way of the dinosaurs. I've had an SQLite-based personal standalone sandbox for some time now as the full extent of my OpenSim administration and I figured with this possibility impending I should see what it's like for a relative newbie like me with no MySQL experience to set up a standalone using it. I'm on Vista 64. It wound up taking me about three hours to get fully up and running. Installing MySQL itself was trivial but once I had it installed I was at a bit of a loss on how to configure it. I didn't even really know what I needed to do, let alone how to do it. The connection strings in the default ini (from OSGrid's install) suggested I should set up have a database named opensim and a user named opensim to go along with it but there wasn't much else to go on. I tried installing Workbench and fumbled around with that for a while until I decided I was stuck down a dead-end. I did some more web-searching, and finally found http://opensimuser.wordpress.com/2008/07/16/opensim-mysql-install-guide/ - it's a year-old blog post and it didn't quite match up with what I wound up needing to do but it pointed me in all the right directions and I got the database set up. Then I ran into a final hitch hunting through the various opensim ini files to track down every place I needed to set up MySQL's connection string. I missed StandaloneCommon.ini, causing my opensim to go through an endless cycle of requesting baked avatar textures and not recognizing that it had received them. Annoying but not too hard to catch on the second go-through. If you do wind up dropping SQLite, here's what would have made the process go much easier for me: * A cookbook setup guide like that blog post to be prominently linked on the wiki (perhaps put a link right in the example ini itself). To avoid reliance on the third party software used in this particular example, perhaps a script to copy and paste into the MySQL command line would be better. * Would it be possible to bring the database-related configuration options closer together in the ini file, to make it easier to set them all up properly? Perhaps have one default connection string that will be used if you leave the others blank, to avoid having to put the same name and password scattered throughout? * I haven't tried making a backup yet but that's going to be another new learning experience. Some sort of cookbook/script for this would be welcome too. All in all, not as bad as I feared. But I'm only part noob so I can see this being a stumbling point for many. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] User services refactoring status
Thanks for your help here, I will check out these connectors, and assess the work involved. From my perspective the web interface and authentication are critical; the two most significant aspects that impact upon my plans. I guess there is a problem in having the development resources to update the web interface. The other major issue mentioned by every organisation I have spoken to is security - but I know you intend to address this. I can appreciate Mic's concern though as changes to the architecture and interfaces are especially expensive in development time - not a demand but it is a significant issue. Are some aspects of the interface more settled than others? I appreciate that this is a judgement call. Mic do you know who else is doing work on PHP/Web Services? Thanks once again. Tom On 5 Jan 2010, at 15:20, d...@metaverseink.com wrote: In my experience, no project is, or should be, 'stable' until it reaches 1.0. Before 1.0 people programming against the core code do it at their own peril, and should not complain. It's completely unrealistic to demand interface stability during early stages, and it's actually quite harmful -- stabilizing on bad design is the worst that can happen to a project. Even after 1.0, interfaces change. Just to point one among many examples that I know first hand: Apache Lucene, changed dramatically from 1.x to 2.0. So I'm not sure what to tell you. Will the interfaces change? Most likely. Will the pace of changes slow down over time? Definitely. When is a good time for people to extend OpenSim 'safely'? Not before 1.0. Mic Bowman wrote: Do you expect those formalized interfaces to remain stable long enough to warrant the effort to create alternative implementations? Others have provided alternative implementations in the past that quickly became obsolete. --mic On Tue, Jan 5, 2010 at 2:17 PM, d...@metaverseink.com mailto:d...@metaverseink.com wrote: Putting PHP in front of the DBs is one of the most natural things to do from here on -- not just the things that Wiredux does, but for a lot more! In fact, the entire collection of OpenSim.Services that are provided as reference implementations can be replaced with implementations in Apache+PHP. Calls from the simulators to the services are now all neatly packaged in OpenSim.Services.Connectors (these are the out connectors). Just browse through those connectors and check out the wire protocols, then do the receiving end in PHP. Many of them are using standard web forms, others use XMLRPC, others use custom-made HTTP-based dialects. Calls from outside to the simulators are packaged in OpenSim.Server.Handlers. Again, check them out and, if not using .NET, write your own client for them. If using .NET/mono you can import the DLL OpenSim.Connectors.dll, and reuse the existing connectors as- is. But that's not all. Since now the interactions between the simulators and the resource services are all formalized in interfaces (OpenSim.Services.Interfaces), and the handlers and connectors in the simulator are loaded dynamically, you can replace the connectors and handlers themselves. In other words, if you want OpenSim to talk web services, roll your own Web Services handlers and connectors under those interfaces, and you're done -- you'll have to use .NET for this part, though. Tom Willans wrote: Hi, First thanks for all your work. I assume from this that the webredux will no longer work without modification and will need updating. ( Thanks again here). Is there any information about the new authentication approach anywhere, if not in detail then an overview. Is LDAP on the horizon? I am mostly interested in linking php based frontends to opensim and hence accessing the database directly. Particularly relevant is moving away from using UUIDs. Please forgive me if I am missing something but I assume there are no web-services that can be called and calling C# from php is not a very good solution. Thanks. Tom On 5 Jan 2010, at 10:37, Ai Austin wrote: At 18:32 04/01/2010, opensim-dev-requ...@lists.berlios.de mailto:opensim-dev-requ...@lists.berlios.de mailto:opensim-dev-requ...@lists.berlios.de mailto:opensim-dev-requ...@lists.berlios.de wrote: To be honest, I don't think Sqlite should be a database type that we (OpenSim) should keep alive in the project, It is useful to have a double click and go out of the box solution which people can try out and test with. One other use of SQLite that I am aware of and fine very useful is for the really simple and handy single region hosted on your own system that is connected to the New World Grid for any avatar using the New World Studio packaged version of Opensim. See http://www.newworldgrid.com/lang/en-us/land/free-land ___ Opensim-dev mailing list
Re: [Opensim-dev] User services refactoring status
I am working on it and it's about to be launched (due to the framework I use, Code Igniter, possibly with a MIT or Apache license, but open source). A soon as I clean the code will be available for public download. It was stable on October but then... Modern Warfare 2 was launched and I love AK-47 :-) I called it unga :-) http://ai-designstudio.net/en/blog/1008 I am planning to make a Python unga using Tornado/Twister frameworks, but I haven't time enough... Greetings 2010/1/6 Tom Willans tom.will...@bessacarr.com Thanks for your help here, I will check out these connectors, and assess the work involved. From my perspective the web interface and authentication are critical; the two most significant aspects that impact upon my plans. I guess there is a problem in having the development resources to update the web interface. The other major issue mentioned by every organisation I have spoken to is security - but I know you intend to address this. I can appreciate Mic's concern though as changes to the architecture and interfaces are especially expensive in development time - not a demand but it is a significant issue. Are some aspects of the interface more settled than others? I appreciate that this is a judgement call. Mic do you know who else is doing work on PHP/Web Services? Thanks once again. Tom On 5 Jan 2010, at 15:20, d...@metaverseink.com wrote: In my experience, no project is, or should be, 'stable' until it reaches 1.0. Before 1.0 people programming against the core code do it at their own peril, and should not complain. It's completely unrealistic to demand interface stability during early stages, and it's actually quite harmful -- stabilizing on bad design is the worst that can happen to a project. Even after 1.0, interfaces change. Just to point one among many examples that I know first hand: Apache Lucene, changed dramatically from 1.x to 2.0. So I'm not sure what to tell you. Will the interfaces change? Most likely. Will the pace of changes slow down over time? Definitely. When is a good time for people to extend OpenSim 'safely'? Not before 1.0. Mic Bowman wrote: Do you expect those formalized interfaces to remain stable long enough to warrant the effort to create alternative implementations? Others have provided alternative implementations in the past that quickly became obsolete. --mic On Tue, Jan 5, 2010 at 2:17 PM, d...@metaverseink.com mailto:d...@metaverseink.com d...@metaverseink.com wrote: Putting PHP in front of the DBs is one of the most natural things to do from here on -- not just the things that Wiredux does, but for a lot more! In fact, the entire collection of OpenSim.Services that are provided as reference implementations can be replaced with implementations in Apache+PHP. Calls from the simulators to the services are now all neatly packaged in OpenSim.Services.Connectors (these are the out connectors). Just browse through those connectors and check out the wire protocols, then do the receiving end in PHP. Many of them are using standard web forms, others use XMLRPC, others use custom-made HTTP-based dialects. Calls from outside to the simulators are packaged in OpenSim.Server.Handlers. Again, check them out and, if not using .NET, write your own client for them. If using .NET/mono you can import the DLL OpenSim.Connectors.dll, and reuse the existing connectors as-is. But that's not all. Since now the interactions between the simulators and the resource services are all formalized in interfaces (OpenSim.Services.Interfaces), and the handlers and connectors in the simulator are loaded dynamically, you can replace the connectors and handlers themselves. In other words, if you want OpenSim to talk web services, roll your own Web Services handlers and connectors under those interfaces, and you're done -- you'll have to use .NET for this part, though. Tom Willans wrote: Hi, First thanks for all your work. I assume from this that the webredux will no longer work without modification and will need updating. ( Thanks again here). Is there any information about the new authentication approach anywhere, if not in detail then an overview. Is LDAP on the horizon? I am mostly interested in linking php based frontends to opensim and hence accessing the database directly. Particularly relevant is moving away from using UUIDs. Please forgive me if I am missing something but I assume there are no web-services that can be called and calling C# from php is not a very good solution. Thanks. Tom On 5 Jan 2010, at 10:37, Ai Austin wrote: At 18:32 04/01/2010, opensim-dev-requ...@lists.berlios.de mailto:opensim-dev-requ...@lists.berlios.deopensim-dev-requ...@lists.berlios.de mailto:opensim-dev-requ...@lists.berlios.deopensim-dev-requ...@lists.berlios.de
Re: [Opensim-dev] User services refactoring status
Getting a bit off topic, but here is another one: http://forge.opensimulator.org/gf/project/hwios cheers, Jeroen Op woensdag 06 januari 2010 16:41:23 schreef Impalah Shenzhou: I am working on it and it's about to be launched (due to the framework I use, Code Igniter, possibly with a MIT or Apache license, but open source). A soon as I clean the code will be available for public download. It was stable on October but then... Modern Warfare 2 was launched and I love AK-47 :-) I called it unga :-) http://ai-designstudio.net/en/blog/1008 I am planning to make a Python unga using Tornado/Twister frameworks, but I haven't time enough... Greetings 2010/1/6 Tom Willans tom.will...@bessacarr.com Thanks for your help here, I will check out these connectors, and assess the work involved. From my perspective the web interface and authentication are critical; the two most significant aspects that impact upon my plans. I guess there is a problem in having the development resources to update the web interface. The other major issue mentioned by every organisation I have spoken to is security - but I know you intend to address this. I can appreciate Mic's concern though as changes to the architecture and interfaces are especially expensive in development time - not a demand but it is a significant issue. Are some aspects of the interface more settled than others? I appreciate that this is a judgement call. Mic do you know who else is doing work on PHP/Web Services? Thanks once again. Tom On 5 Jan 2010, at 15:20, d...@metaverseink.com wrote: In my experience, no project is, or should be, 'stable' until it reaches 1.0. Before 1.0 people programming against the core code do it at their own peril, and should not complain. It's completely unrealistic to demand interface stability during early stages, and it's actually quite harmful -- stabilizing on bad design is the worst that can happen to a project. Even after 1.0, interfaces change. Just to point one among many examples that I know first hand: Apache Lucene, changed dramatically from 1.x to 2.0. So I'm not sure what to tell you. Will the interfaces change? Most likely. Will the pace of changes slow down over time? Definitely. When is a good time for people to extend OpenSim 'safely'? Not before 1.0. Mic Bowman wrote: Do you expect those formalized interfaces to remain stable long enough to warrant the effort to create alternative implementations? Others have provided alternative implementations in the past that quickly became obsolete. --mic On Tue, Jan 5, 2010 at 2:17 PM, d...@metaverseink.com mailto:d...@metaverseink.com d...@metaverseink.com wrote: Putting PHP in front of the DBs is one of the most natural things to do from here on -- not just the things that Wiredux does, but for a lot more! In fact, the entire collection of OpenSim.Services that are provided as reference implementations can be replaced with implementations in Apache+PHP. Calls from the simulators to the services are now all neatly packaged in OpenSim.Services.Connectors (these are the out connectors). Just browse through those connectors and check out the wire protocols, then do the receiving end in PHP. Many of them are using standard web forms, others use XMLRPC, others use custom-made HTTP-based dialects. Calls from outside to the simulators are packaged in OpenSim.Server.Handlers. Again, check them out and, if not using .NET, write your own client for them. If using .NET/mono you can import the DLL OpenSim.Connectors.dll, and reuse the existing connectors as-is. But that's not all. Since now the interactions between the simulators and the resource services are all formalized in interfaces (OpenSim.Services.Interfaces), and the handlers and connectors in the simulator are loaded dynamically, you can replace the connectors and handlers themselves. In other words, if you want OpenSim to talk web services, roll your own Web Services handlers and connectors under those interfaces, and you're done -- you'll have to use .NET for this part, though. Tom Willans wrote: Hi, First thanks for all your work. I assume from this that the webredux will no longer work without modification and will need updating. ( Thanks again here). Is there any information about the new authentication approach anywhere, if not in detail then an overview. Is LDAP on the horizon? I am mostly interested in linking php based frontends to opensim and hence accessing the database directly. Particularly relevant is moving away from using UUIDs. Please forgive me if I am missing something but I assume there are no web-services that can be called and calling
Re: [Opensim-dev] User services refactoring status
Tom Willans wrote: Are some aspects of the interface more settled than others? I appreciate that this is a judgement call. Yes, some aspects are more settled than others. First, let me point out where this comes from, so that you and others can understand better. Up to recently, there was no such thing as OpenSim.Services.Interfaces, nor the companions OpenSim.Services.Connectors and OpenSim.Server.Handlers. The interaction between the simulator and the resource services, and among the resource services themselves, was a mess. I don't mean it in a criticizing attitude, early-stage code is usually a mess. The broad stokes were there, and were really good, but the details were a complete mess. Simple questions like what handlers are there? or what are the resource service interfaces? were a challenge to answer, interfaces and handlers were spread all over the code, special cases were pervasive, classes were being used directly instead of interfaces, etc. The user services, in particular, were a nightmare, with duplication running rampant because of standalone vs grid mode, and the code being on the verge of bipolar disorder. Users, agents and avatars were being used interchangeably, with no conceptual distinction, misnomers everywhere, etc. This refactoring's main goal is to depart from that chaotic mess and to instill order in the code base. It is primarily a *refactoring*, meaning that code has moved from one namespace to another, but it is also a rewrite -- because in the process of revisiting the code it was clear that things should be done better than they were being done. In particular, harmful hard-coded instantiations of classes were replaced by dynamic loading and instantiation. The core of this is OpenSim.Server.Base.Utils.LoadPlugin -- this is the core of the ROBUST model. Having said that, let me now explain how people who plan to extend OpenSim should be looking at it. The main contract between the core code and developers of resource services is the collection of interfaces in OpenSim.Services.Interfaces. This is what the simulators call, can't get around hard-coded calls to those interfaces. Those interfaces will stabilize very quickly. Most of them are stable already, with the notable exception of IInventoryService which still needs love. But all others will be stable at 0.7. Now is the right time for people to look at those interfaces and send feedback about which things you think are missing. The next level of reuse is the code in OpenSim.Services.Connectors and OpenSim.Server.Handlers. This code is less important than the interfaces, because it's invisible to the simulators, therefore ppl should be more careful about relying on it. This is quite an important point that I don't think many people grasp yet, so let me explain. In most systems, the network protocols are fixed. People go to great lengths discussing them ad-nauseum in meetings and committees, to settle on the right data formats, the right data, etc. NOT HERE. The network protocols in OpenSim are now dynamically loaded, and therefore replaceable. There is no such thing as *the* network protocol between the simulator and, say, the asset server. There can be many -- you can roll your own. There are reference implementations in the core distribution, but that's exactly what they are: reference implementations, they are not fixed protocols. As such, people should be careful about relying on those reference implementations. So, to sum it up: the main contract is OpenSim.Services.Interfaces and those are going to be stable very soon. The level right under it, OpenSim.Server.Handlers and OpenSim.Services.Connectors can also be relied upon but it's less stable. I'm still not happy with many of those, so they will change after 0.7. People who don't want to put up with these changes may want to roll their own network protocols. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] User services refactoring status
The comment below about ad-nauseum discussions is at least a mis-representation and borders on silly. This isn't an either/or situation. You can have discipline, documentation, and well thought out interfaces *AND* make rapid progress. OpenSim development has chosen a more-than-usual anarchist process (anarchist is the word I've heard core developers use to describe themselves)... and that's a very reasonable choice for this project (and a choice that is clearly communicated). Its an approach that leads to rapid innovation and (to put it mildly) passionate energy in the coding. It also has other consequences... For example, it alienates the user community who would like to take the code, use it and extend it. Yes.. you can claim that we're all too early. That we should wait for 1.0. Until then, for all its claims to extensibility, the cost of maintaining extensions against a shifting-sand set of interfaces is very high... that is, the development process that has been chosen for OpenSim works against the basic goals of the project. The normal response to this kind of message is get in and fix it. And I completely agree. And we have (financial support, code, marketing, etc). And... the question we continue to ask ourselves is whether our (meaning Intel) dev resources would be better focused on work specific to our customers collaborators on a release we choose to freeze or whether we should continue to wait for and work towards 1.0. Please note that I'm not suggesting that OpenSim core development change (or we would lose all the benefits of the process)... I'm simply saying that the current development process forces us as users to decide when the platform has reached an appropriate level of functionality and to focus our resources on that version. --mic On Wed, Jan 6, 2010 at 8:10 AM, d...@metaverseink.com wrote: In most systems, the network protocols are fixed. People go to great lengths discussing them ad-nauseum in meetings and committees, to settle on the right data formats, the right data, etc. NOT HERE. The network protocols in OpenSim are now dynamically loaded, and therefore replaceable. There is no such thing as *the* network protocol between the simulator and, say, the asset server. There can be many -- you can roll your own. There are reference implementations in the core distribution, but that's exactly what they are: reference implementations, they are not fixed protocols. As such, people should be careful about relying on those reference implementations. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] User services refactoring status
A perfectly valid position; a dilemma for people who like OpenSim so much that hate having to wait for 1.0 to make cool things with it. Forking is always an option, especially for organizations who have the resources to support the fork. Personally, I'd be sad if you decide to fork, since the Intel devs are super-duper contributors to OpenSim. But, obviously, I understand the need for a layer between raw development and end users... and that's one thing that the OpenSim project has sucked at really bad, intentionally or not. Ad-nausum protocol discussions: I've been in those meetings before. Not here, and not anymore. Since reflection came into mainstream PLs, you can now avoid those discussions by adding a meta-level, and that's what happened here :) XMLRPC vs REST vs LLx? Protocol buffers vs .NET serialization? - have it your way, the simulator doesn't care, it only sees interfaces. For example, it looks like it's going to be possible to rewrite OGP as a different handler for the simulation service... but that's a different conversation. Mic Bowman wrote: The comment below about ad-nauseum discussions is at least a mis-representation and borders on silly. This isn't an either/or situation. You can have discipline, documentation, and well thought out interfaces *AND* make rapid progress. OpenSim development has chosen a more-than-usual anarchist process (anarchist is the word I've heard core developers use to describe themselves)... and that's a very reasonable choice for this project (and a choice that is clearly communicated). Its an approach that leads to rapid innovation and (to put it mildly) passionate energy in the coding. It also has other consequences... For example, it alienates the user community who would like to take the code, use it and extend it. Yes.. you can claim that we're all too early. That we should wait for 1.0. Until then, for all its claims to extensibility, the cost of maintaining extensions against a shifting-sand set of interfaces is very high... that is, the development process that has been chosen for OpenSim works against the basic goals of the project. The normal response to this kind of message is get in and fix it. And I completely agree. And we have (financial support, code, marketing, etc). And... the question we continue to ask ourselves is whether our (meaning Intel) dev resources would be better focused on work specific to our customers collaborators on a release we choose to freeze or whether we should continue to wait for and work towards 1.0. Please note that I'm not suggesting that OpenSim core development change (or we would lose all the benefits of the process)... I'm simply saying that the current development process forces us as users to decide when the platform has reached an appropriate level of functionality and to focus our resources on that version. --mic On Wed, Jan 6, 2010 at 8:10 AM, d...@metaverseink.com mailto:d...@metaverseink.com wrote: In most systems, the network protocols are fixed. People go to great lengths discussing them ad-nauseum in meetings and committees, to settle on the right data formats, the right data, etc. NOT HERE. The network protocols in OpenSim are now dynamically loaded, and therefore replaceable. There is no such thing as *the* network protocol between the simulator and, say, the asset server. There can be many -- you can roll your own. There are reference implementations in the core distribution, but that's exactly what they are: reference implementations, they are not fixed protocols. As such, people should be careful about relying on those reference implementations. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] User services refactoring status
Thanks for this - it is a helpful clarification. I rarely mean criticism in a personal way so appreciate the background. I have looked at the work involved and there is quite a lot. I appreciate where Mic is coming from as I have the same dilemma ( with even fewer resources than Intel!). On 6 Jan 2010, at 16:10, d...@metaverseink.com wrote: Tom Willans wrote: Are some aspects of the interface more settled than others? I appreciate that this is a judgement call. Yes, some aspects are more settled than others. First, let me point out where this comes from, so that you and others can understand better. Up to recently, there was no such thing as OpenSim.Services.Interfaces, nor the companions OpenSim.Services.Connectors and OpenSim.Server.Handlers. The interaction between the simulator and the resource services, and among the resource services themselves, was a mess. I don't mean it in a criticizing attitude, early-stage code is usually a mess. The broad stokes were there, and were really good, but the details were a complete mess. Simple questions like what handlers are there? or what are the resource service interfaces? were a challenge to answer, interfaces and handlers were spread all over the code, special cases were pervasive, classes were being used directly instead of interfaces, etc. The user services, in particular, were a nightmare, with duplication running rampant because of standalone vs grid mode, and the code being on the verge of bipolar disorder. Users, agents and avatars were being used interchangeably, with no conceptual distinction, misnomers everywhere, etc. This refactoring's main goal is to depart from that chaotic mess and to instill order in the code base. It is primarily a *refactoring*, meaning that code has moved from one namespace to another, but it is also a rewrite -- because in the process of revisiting the code it was clear that things should be done better than they were being done. In particular, harmful hard-coded instantiations of classes were replaced by dynamic loading and instantiation. The core of this is OpenSim.Server.Base.Utils.LoadPlugin -- this is the core of the ROBUST model. Having said that, let me now explain how people who plan to extend OpenSim should be looking at it. The main contract between the core code and developers of resource services is the collection of interfaces in OpenSim.Services.Interfaces. This is what the simulators call, can't get around hard-coded calls to those interfaces. Those interfaces will stabilize very quickly. Most of them are stable already, with the notable exception of IInventoryService which still needs love. But all others will be stable at 0.7. Now is the right time for people to look at those interfaces and send feedback about which things you think are missing. The next level of reuse is the code in OpenSim.Services.Connectors and OpenSim.Server.Handlers. This code is less important than the interfaces, because it's invisible to the simulators, therefore ppl should be more careful about relying on it. This is quite an important point that I don't think many people grasp yet, so let me explain. In most systems, the network protocols are fixed. People go to great lengths discussing them ad-nauseum in meetings and committees, to settle on the right data formats, the right data, etc. NOT HERE. The network protocols in OpenSim are now dynamically loaded, and therefore replaceable. There is no such thing as *the* network protocol between the simulator and, say, the asset server. There can be many -- you can roll your own. There are reference implementations in the core distribution, but that's exactly what they are: reference implementations, they are not fixed protocols. As such, people should be careful about relying on those reference implementations. So, to sum it up: the main contract is OpenSim.Services.Interfaces and those are going to be stable very soon. The level right under it, OpenSim.Server.Handlers and OpenSim.Services.Connectors can also be relied upon but it's less stable. I'm still not happy with many of those, so they will change after 0.7. People who don't want to put up with these changes may want to roll their own network protocols. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev Tom Willans Managing Director Bessacarr Publications Ltd 3 Highfield, Hatton Park, Warwick, CV35 7TQ tom.will...@bessacarr.com +44 (0) 1926 402055 +44 (0) 121 288 0281 Registered in England and Wales at the above address. Company No: 4925067. VAT No:GB 823 9317 24. This e-mail is confidential and intended solely for the use of the individual to whom it is addressed. Any views or opinions presented are solely those of the author and do not necessarily represent those of Bessacarr Publications Ltd. If you are not the intended recipient you have received this
Re: [Opensim-dev] User services refactoring status
On Wed, Jan 6, 2010 at 10:11 AM, d...@metaverseink.com wrote: Ad-nausum protocol discussions: I've been in those meetings before. Not here, and not anymore. Since reflection came into mainstream PLs, you can now avoid those discussions by adding a meta-level, and that's what happened here :) Ad-nauseum discussions are a function of how a meeting is run. You can have well thought out, consensus-based protocol discussions that are very productive and very focused. Likewise... reflection can be used to simplify experimentation/extension or it can be used for lazy programming. The tools matter far less than the people who run them. In this case, one of the barriers we feel to productive public discussion (and probably documentation) about long-term, stable interfaces is a lack of belief that the discussion will matter in a substantial way to what gets coded. That is, if we went off built the php/apache interfaces, we would have no influence over changes in the core would therefore be completely subject to any decisions core makes. (Feels like taxation without representation or something like that... :-) So... You say that we can go off build what we want... but that's only cost-effective if we fork or freeze (or wait)... --mic ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] User services refactoring status
Mic Bowman wrote: In this case, one of the barriers we feel to productive public discussion (and probably documentation) about long-term, stable interfaces is a lack of belief that the discussion will matter in a substantial way to what gets coded. That is, if we went off built the php/apache interfaces, we would have no influence over changes in the core would therefore be completely subject to any decisions core makes. (Feels like taxation without representation or something like that... :-) So... You say that we can go off build what we want... but that's only cost-effective if we fork or freeze (or wait)... Well, that's not exactly true that you don't have a say, since 2 core devs are your employees :) But wrt to stabilization, as I said, those interfaces are the main contract. Notice that these interfaces didn't exist, as such, before. Now they do. Before now, no one here could point to a piece of the code base and tell you hey, here's the contract. Now we can. I'm hoping that, after some minor clean-ups (exception: IInventoryService needs a major cleanup) those interfaces will freeze. I'd be very surprised if those interfaces will go through major changes after 0.7. That's my word only, I don't speak for the entire project, but, really, I'd be *very* surprised. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] User services refactoring status
The interfaces have always existed. They were undocumented scattered across files, but you can't have a distributed system without interfaces. What you've done is make them less internal, slightly better documented, and moved to a single set of files (and improved them). It's a commitment to a stable set of well-understood interfaces that makes extensibility possible (or more accurately... cost-effective). Whether they're in an I* file is mostly a matter of convenience. BTW... this is not a complaint about the work that is being done. Or about the refactoring. This is good stuff. And a commitment to treating them like real, persistent interfaces is the next step. --mic On Wed, Jan 6, 2010 at 10:52 AM, d...@metaverseink.com wrote: Mic Bowman wrote: In this case, one of the barriers we feel to productive public discussion (and probably documentation) about long-term, stable interfaces is a lack of belief that the discussion will matter in a substantial way to what gets coded. That is, if we went off built the php/apache interfaces, we would have no influence over changes in the core would therefore be completely subject to any decisions core makes. (Feels like taxation without representation or something like that... :-) So... You say that we can go off build what we want... but that's only cost-effective if we fork or freeze (or wait)... Well, that's not exactly true that you don't have a say, since 2 core devs are your employees :) But wrt to stabilization, as I said, those interfaces are the main contract. Notice that these interfaces didn't exist, as such, before. Now they do. Before now, no one here could point to a piece of the code base and tell you hey, here's the contract. Now we can. I'm hoping that, after some minor clean-ups (exception: IInventoryService needs a major cleanup) those interfaces will freeze. I'd be very surprised if those interfaces will go through major changes after 0.7. That's my word only, I don't speak for the entire project, but, really, I'd be *very* surprised. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] User services refactoring status
Bryan Derksen wrote: On 04/01/2010 9:02 AM, d...@metaverseink.com wrote: Unless someone steps in and takes care of the SQLite connector, I'm afraid it will go the way of the dinosaurs. I've had an SQLite-based personal standalone sandbox for some time now as the full extent of my OpenSim administration and I figured with this possibility impending I should see what it's like for a relative newbie like me with no MySQL experience to set up a standalone using it. I'm on Vista 64. It wound up taking me about three hours to get fully up and running. Installing MySQL itself was trivial but once I had it installed I was at a bit of a loss on how to configure it. I didn't even really know what I needed to do, let alone how to do it. The connection strings in the default ini (from OSGrid's install) suggested I should set up have a database named opensim and a user named opensim to go along with it but there wasn't much else to go on. I tried installing Workbench and fumbled around with that for a while until I decided I was stuck down a dead-end. I did some more web-searching, and finally found http://opensimuser.wordpress.com/2008/07/16/opensim-mysql-install-guide/ - it's a year-old blog post and it didn't quite match up with what I wound up needing to do but it pointed me in all the right directions and I got the database set up. Then I ran into a final hitch hunting through the various opensim ini files to track down every place I needed to set up MySQL's connection string. I missed StandaloneCommon.ini, causing my opensim to go through an endless cycle of requesting baked avatar textures and not recognizing that it had received them. Annoying but not too hard to catch on the second go-through. If you do wind up dropping SQLite, here's what would have made the process go much easier for me: * A cookbook setup guide like that blog post to be prominently linked on the wiki (perhaps put a link right in the example ini itself). To avoid reliance on the third party software used in this particular example, perhaps a script to copy and paste into the MySQL command line would be better. While you were researching, did you come across the wiki page linked off the configuration instructions http://opensimulator.org/wiki/Mysql-config ? I realize now that when I was last rewriting the configuration instructions I foolishly assumed that this page was up-to-date - of course, it's not. I guess I also implicitly assumed that the example mysql strings in the ini would be enough to go on. It doesn't sound like it. * Would it be possible to bring the database-related configuration options closer together in the ini file, to make it easier to set them all up properly? Perhaps have one default connection string that will be used if you leave the others blank, to avoid having to put the same name and password scattered throughout? I agree - changing all the strings is a pita. Some kind of default with specific exceptions if required sounds good to me. * I haven't tried making a backup yet but that's going to be another new learning experience. Some sort of cookbook/script for this would be welcome too. This may be overkill - if you want to back up the whole database we're just talking about mysql's native backup procedures (for which there is, naturally, tons of existing documentation on the web). More specifically, individual regions and inventory can be backed up using OAR and IAR respectively - these should be googleable. All in all, not as bad as I feared. But I'm only part noob so I can see this being a stumbling point for many. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev -- Justin Clark-Casey (justincc) http://justincc.org http://twitter.com/justincc ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] User services refactoring status
d...@metaverseink.com wrote: Tom Willans wrote: Are some aspects of the interface more settled than others? I appreciate that this is a judgement call. Yes, some aspects are more settled than others. First, let me point out where this comes from, so that you and others can understand better. Up to recently, there was no such thing as OpenSim.Services.Interfaces, nor the companions OpenSim.Services.Connectors and OpenSim.Server.Handlers. The interaction between the simulator and the resource services, and among the resource services themselves, was a mess. I don't mean it in a criticizing attitude, early-stage code is usually a mess. The broad stokes were there, and were really good, but the details were a complete mess. Simple questions like what handlers are there? or what are the resource service interfaces? were a challenge to answer, interfaces and handlers were spread all over the code, special cases were pervasive, classes were being used directly instead of interfaces, etc. The user services, in particular, were a nightmare, with duplication running rampant because of standalone vs grid mode, and the code being on the verge of bipolar disorder. Users, agents and avatars were being used interchangeably, with no conceptual distinction, misnomers everywhere, etc. This refactoring's main goal is to depart from that chaotic mess and to instill order in the code base. It is primarily a *refactoring*, meaning that code has moved from one namespace to another, but it is also a rewrite -- because in the process of revisiting the code it was clear that things should be done better than they were being done. In particular, harmful hard-coded instantiations of classes were replaced by dynamic loading and instantiation. The core of this is OpenSim.Server.Base.Utils.LoadPlugin -- this is the core of the ROBUST model. Having said that, let me now explain how people who plan to extend OpenSim should be looking at it. Is this documented on the wiki, such as at http://opensimulator.org/wiki/OpenSim_Services_and_Service_Connectors ? Unless it's somewhere more consumable than just this mailing list the information is going to get lost. The main contract between the core code and developers of resource services is the collection of interfaces in OpenSim.Services.Interfaces. This is what the simulators call, can't get around hard-coded calls to those interfaces. Those interfaces will stabilize very quickly. Most of them are stable already, with the notable exception of IInventoryService which still needs love. But all others will be stable at 0.7. Now is the right time for people to look at those interfaces and send feedback about which things you think are missing. The next level of reuse is the code in OpenSim.Services.Connectors and OpenSim.Server.Handlers. This code is less important than the interfaces, because it's invisible to the simulators, therefore ppl should be more careful about relying on it. This is quite an important point that I don't think many people grasp yet, so let me explain. In most systems, the network protocols are fixed. People go to great lengths discussing them ad-nauseum in meetings and committees, to settle on the right data formats, the right data, etc. NOT HERE. The network protocols in OpenSim are now dynamically loaded, and therefore replaceable. There is no such thing as *the* network protocol between the simulator and, say, the asset server. There can be many -- you can roll your own. There are reference implementations in the core distribution, but that's exactly what they are: reference implementations, they are not fixed protocols. As such, people should be careful about relying on those reference implementations. Reference implementations seems a misnomer here - such code would constitute example implementations since they don't act as a reference for a spec. Anyway, I think that we should be more ambitious than just have example implementations. In my opinion, we should have wire protocol implementations in core that aim for a high level of stability but with room for evolution, just as Apache embodied the HTTP procotol which was explicitly designed with these properties in mind (as outlined by Fielding in his dissertation about the architecture of the web - http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm). People who want to experiment with other ways of doing things will still be very free to do so. If we don't have this kind of thing in OpenSim then the interoperability focus will move to downstream projects that do attempt this, with all the pros (freedom to narrowly target diverse use cases) and cons (fragmentation) that this involves. So, to sum it up: the main contract is OpenSim.Services.Interfaces and those are going to be stable very soon. The level right under it, OpenSim.Server.Handlers and
Re: [Opensim-dev] User services refactoring status
d...@metaverseink.com wrote: A perfectly valid position; a dilemma for people who like OpenSim so much that hate having to wait for 1.0 to make cool things with it. Forking is always an option, especially for organizations who have the resources to support the fork. Personally, I'd be sad if you decide to fork, since the Intel devs are super-duper contributors to OpenSim. But, obviously, I understand the need for a layer between raw development and end users... and that's one thing that the OpenSim project has sucked at really bad, intentionally or not. I think that we should try to avoid forking at this stage if at all possible. Let's not kid ourselves - OpenSim doesn't have that much weight behind it yet. Diluting our efforts may prove fatal. From what I'm hearing, I actually think that we could aim for a 1.0 after ROBUST and the upcoming mesh work have proven somewhat stable. From my point of view, this would absolutely require interfaces with proper interface and method documentation. Up until that point I don't think that we can afford to be too squeamish about changing things - there's a hell of a lot of crap and undocumented weirdness at the point where people would need to plug into the core of OpenSim. Even such a 1.0 would have tons of bugs - it would be more like a commercial software 1.0 where nobody expects a usable product until 3.0 (and even then :) Ad-nausum protocol discussions: I've been in those meetings before. Not here, and not anymore. Since reflection came into mainstream PLs, you can now avoid those discussions by adding a meta-level, and that's what happened here :) XMLRPC vs REST vs LLx? Protocol buffers vs .NET serialization? - have it your way, the simulator doesn't care, it only sees interfaces. For example, it looks like it's going to be possible to rewrite OGP as a different handler for the simulation service... but that's a different conversation. Mic Bowman wrote: The comment below about ad-nauseum discussions is at least a mis-representation and borders on silly. This isn't an either/or situation. You can have discipline, documentation, and well thought out interfaces *AND* make rapid progress. OpenSim development has chosen a more-than-usual anarchist process (anarchist is the word I've heard core developers use to describe themselves)... and that's a very reasonable choice for this project (and a choice that is clearly communicated). Its an approach that leads to rapid innovation and (to put it mildly) passionate energy in the coding. It also has other consequences... For example, it alienates the user community who would like to take the code, use it and extend it. Yes.. you can claim that we're all too early. That we should wait for 1.0. Until then, for all its claims to extensibility, the cost of maintaining extensions against a shifting-sand set of interfaces is very high... that is, the development process that has been chosen for OpenSim works against the basic goals of the project. The normal response to this kind of message is get in and fix it. And I completely agree. And we have (financial support, code, marketing, etc). And... the question we continue to ask ourselves is whether our (meaning Intel) dev resources would be better focused on work specific to our customers collaborators on a release we choose to freeze or whether we should continue to wait for and work towards 1.0. Please note that I'm not suggesting that OpenSim core development change (or we would lose all the benefits of the process)... I'm simply saying that the current development process forces us as users to decide when the platform has reached an appropriate level of functionality and to focus our resources on that version. --mic On Wed, Jan 6, 2010 at 8:10 AM, d...@metaverseink.com mailto:d...@metaverseink.com wrote: In most systems, the network protocols are fixed. People go to great lengths discussing them ad-nauseum in meetings and committees, to settle on the right data formats, the right data, etc. NOT HERE. The network protocols in OpenSim are now dynamically loaded, and therefore replaceable. There is no such thing as *the* network protocol between the simulator and, say, the asset server. There can be many -- you can roll your own. There are reference implementations in the core distribution, but that's exactly what they are: reference implementations, they are not fixed protocols. As such, people should be careful about relying on those reference implementations. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev -- Justin Clark-Casey (justincc) http://justincc.org http://twitter.com/justincc ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de
Re: [Opensim-dev] User services refactoring status
Hi, at this time, I believe the interfaces might grow, but are unlikely to change existing methods. Two methods on the inventory interface are slated to be dropped, and already marked obsolete. Everything else can be considered more stable than anything we used to have. Melanie d...@metaverseink.com wrote: Mic Bowman wrote: In this case, one of the barriers we feel to productive public discussion (and probably documentation) about long-term, stable interfaces is a lack of belief that the discussion will matter in a substantial way to what gets coded. That is, if we went off built the php/apache interfaces, we would have no influence over changes in the core would therefore be completely subject to any decisions core makes. (Feels like taxation without representation or something like that... :-) So... You say that we can go off build what we want... but that's only cost-effective if we fork or freeze (or wait)... Well, that's not exactly true that you don't have a say, since 2 core devs are your employees :) But wrt to stabilization, as I said, those interfaces are the main contract. Notice that these interfaces didn't exist, as such, before. Now they do. Before now, no one here could point to a piece of the code base and tell you hey, here's the contract. Now we can. I'm hoping that, after some minor clean-ups (exception: IInventoryService needs a major cleanup) those interfaces will freeze. I'd be very surprised if those interfaces will go through major changes after 0.7. That's my word only, I don't speak for the entire project, but, really, I'd be *very* surprised. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] User services refactoring status
On 06/01/2010 12:33 PM, Justin Clark-Casey wrote: Bryan Derksen wrote: On 04/01/2010 9:02 AM, d...@metaverseink.com wrote: * A cookbook setup guide like that blog post to be prominently linked on the wiki (perhaps put a link right in the example ini itself). To avoid reliance on the third party software used in this particular example, perhaps a script to copy and paste into the MySQL command line would be better. While you were researching, did you come across the wiki page linked off the configuration instructions http://opensimulator.org/wiki/Mysql-config ? I realize now that when I was last rewriting the configuration instructions I foolishly assumed that this page was up-to-date - of course, it's not. That was the page that led me to the blog post that actually told me what I needed to know to set up the database. But the instructions on the opensim wiki itself were so sketchy that I didn't really consider them instructions. I quote the entirety of the wiki's instructions on how to create the database here: Create database opensim (using MySql command) Needless to say, I'd already guessed that I needed to do that. It was the how part I was really needing. :) * I haven't tried making a backup yet but that's going to be another new learning experience. Some sort of cookbook/script for this would be welcome too. This may be overkill - if you want to back up the whole database we're just talking about mysql's native backup procedures (for which there is, naturally, tons of existing documentation on the web). More specifically, individual regions and inventory can be backed up using OAR and IAR respectively - these should be googleable. Yeah, I already use OAR and IAR backups, I used them to populate my MySQL database after I had it set up. But it's not really convenient in many situations. My standalone has six sims, plus my inventory, so that's six region-change and seven archive-save commands I need to execute whenever I make a backup. I've created a command script to do it, of course, but by the same token I could just use a batch file to make a backup of the MySQL database. Restoring from OARs and IARs has additional problems. My inventory gets put into a new set of subdirectories nested off my root, requiring manual cleanup to put it all back where it came from. All of the scripts in my regions need to be manually reset - the console command doesn't seem to work, I have to do it in the viewer by bulk-selecting everything. And there's something wrong with how OpenSim is storing ground textures and water levels, I've found that after I restore my OARs I need to go around to each sim in turn and manually fiddle with the terrain textures to force OpenSim to save them properly. I know that these are all bugs that will eventually be fixed the right way, but in the meantime it'd just be so much easier to click a one-step batch file that puts the database back the way it used to be. And anything that makes backups easier is likely to save users a lot of work down the road. They've saved my bacon innumerable times. :) ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] User services refactoring status
On 06/01/2010 7:26 PM, Bryan Derksen wrote: I quote the entirety of the wiki's instructions on how to create the database here: Create database opensim (using MySql command) Needless to say, I'd already guessed that I needed to do that. It was the how part I was really needing. :) Oh, fiddlesticks. Is there some corollary of the every spelling flame contains at least one spelling error that applies here? _Now_ I notice that there's more extensive creating the database instructions down at the bottom of the page. In my feeble defense it's buried inside the grid mode configuration section, which I skipped because I wasn't trying to set up a grid mode sim. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] User services refactoring status
At 18:32 04/01/2010, opensim-dev-requ...@lists.berlios.de wrote: To be honest, I don't think Sqlite should be a database type that we (OpenSim) should keep alive in the project, It is useful to have a double click and go out of the box solution which people can try out and test with. One other use of SQLite that I am aware of and fine very useful is for the really simple and handy single region hosted on your own system that is connected to the New World Grid for any avatar using the New World Studio packaged version of Opensim. See http://www.newworldgrid.com/lang/en-us/land/free-land ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] User services refactoring status
Hi, First thanks for all your work. I assume from this that the webredux will no longer work without modification and will need updating. ( Thanks again here). Is there any information about the new authentication approach anywhere, if not in detail then an overview. Is LDAP on the horizon? I am mostly interested in linking php based frontends to opensim and hence accessing the database directly. Particularly relevant is moving away from using UUIDs. Please forgive me if I am missing something but I assume there are no web-services that can be called and calling C# from php is not a very good solution. Thanks. Tom On 5 Jan 2010, at 10:37, Ai Austin wrote: At 18:32 04/01/2010, opensim-dev-requ...@lists.berlios.de wrote: To be honest, I don't think Sqlite should be a database type that we (OpenSim) should keep alive in the project, It is useful to have a double click and go out of the box solution which people can try out and test with. One other use of SQLite that I am aware of and fine very useful is for the really simple and handy single region hosted on your own system that is connected to the New World Grid for any avatar using the New World Studio packaged version of Opensim. See http://www.newworldgrid.com/lang/en-us/land/free-land ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev Tom Willans Managing Director Bessacarr Publications Ltd 3 Highfield, Hatton Park, Warwick, CV35 7TQ tom.will...@bessacarr.com +44 (0) 1926 402055 +44 (0) 121 288 0281 Registered in England and Wales at the above address. Company No: 4925067. VAT No:GB 823 9317 24. This e-mail is confidential and intended solely for the use of the individual to whom it is addressed. Any views or opinions presented are solely those of the author and do not necessarily represent those of Bessacarr Publications Ltd. If you are not the intended recipient you have received this e-mail in error and that any use, dissemination, forwarding, printing or copying of this e-mail is strictly prohibited. Please return it to the sender immediately. The contents of this message may be legally privileged. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] User services refactoring status
Daniel Smith wrote: As a developer of other things, but a user of OpenSim, I would say 'keep sqlite'. Keep the barriers to entry as low as possible. If someone wants to try out OpenSim, make it easy for them. Put your end-user hat on for a moment. I would usually make the same argument and this was why I did feel a preference keeping sqlite. However, on reflection, I'm not sure whether it actually helps that much. OpenSim is always going to be somewhat complicated to set up and run so the added necessity to install a database as well doesn't seem too onerous to me. Mysql is a pretty simple install on all platforms. We also quite often seem to get situations where someone has started off with sqlite and later realizes that they need to convert everything to mysql in order to grow. This can be an awkward process. In addition, we already have a situation where some things are not implemented in sqlite (afaik, attachment persistence still isn't implemented there). It might be better if we don't make the end-user suffer these issues. Anyway, as Diva said, all this really depends on people stepping up to make the necessary code changes for sqlite. If people do then it will remain in the codebase. If nobody does then I think that we may be better off removing it for now. cheers, Daniel On Mon, Jan 4, 2010 at 11:57 AM, Robert Martin robertl...@gmail.com mailto:robertl...@gmail.com wrote: Just adding my thoughts given that XAMP is very easy to setup (heck it would be simple to just have a pre-setup XAMP module as an add-on download) sqlite is not really needed. side question i have a diva install where the DB crashed midway during the first migration stage do i need to dump the tables and start over?? -- Robert L Martin ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de mailto:Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev -- Daniel Smith - Sonoma County, California http://daniel.org/resume ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev -- Justin Clark-Casey (justincc) http://justincc.org http://twitter.com/justincc ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] User services refactoring status
I'm neutral about keeping support for SQLite in core. For me, it's all a matter of someone taking the lead on maintaining it. Honestly, I agree with Justin, and that's the reason why I'm not doing that maintenance work myself. Having a no-installation OpenSim is very nice just to make it work and to have a feel for what OpenSim can do, but I think that the particular implementation of that concept -- with SQLite -- is quite deceiving. No one in his/her right mind would use SQLite as the DB for serious uses of OpenSim, just like no one uses it as the backend to web applications (there are always exceptions to every rule, of course!). As such, starting off with SQLite, liking OpenSim, and then discovering that one needs to migrate the data from SQLite to another DB system is not situation that we should induce people into. In order to implement the no-installation concept, which is a good concept, I'd much rather have an in-memory DB layer with no persistence at all. All data would disappear once the sim shuts down. That way it would be very clear to everyone that if they want persistence they need to think and research about which database system works for them. In some rare cases, people may come to the conclusion that SQLite is what works best for them. Those people should take the lead on maintaining the SQLite OpenSim connector. Justin Clark-Casey wrote: Daniel Smith wrote: As a developer of other things, but a user of OpenSim, I would say 'keep sqlite'. Keep the barriers to entry as low as possible. If someone wants to try out OpenSim, make it easy for them. Put your end-user hat on for a moment. I would usually make the same argument and this was why I did feel a preference keeping sqlite. However, on reflection, I'm not sure whether it actually helps that much. OpenSim is always going to be somewhat complicated to set up and run so the added necessity to install a database as well doesn't seem too onerous to me. Mysql is a pretty simple install on all platforms. We also quite often seem to get situations where someone has started off with sqlite and later realizes that they need to convert everything to mysql in order to grow. This can be an awkward process. In addition, we already have a situation where some things are not implemented in sqlite (afaik, attachment persistence still isn't implemented there). It might be better if we don't make the end-user suffer these issues. Anyway, as Diva said, all this really depends on people stepping up to make the necessary code changes for sqlite. If people do then it will remain in the codebase. If nobody does then I think that we may be better off removing it for now. cheers, Daniel On Mon, Jan 4, 2010 at 11:57 AM, Robert Martin robertl...@gmail.com mailto:robertl...@gmail.com wrote: Just adding my thoughts given that XAMP is very easy to setup (heck it would be simple to just have a pre-setup XAMP module as an add-on download) sqlite is not really needed. side question i have a diva install where the DB crashed midway during the first migration stage do i need to dump the tables and start over?? -- Robert L Martin ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de mailto:Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev -- Daniel Smith - Sonoma County, California http://daniel.org/resume ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] User services refactoring status
It's not just a name change; the interface has changed too, it's much cleaner. (login_to_simulator still exists, obviously -- that's the method called by the LL client, it's a method of the LLLogin service) Once we're done with this refactoring, all (well, most...) network handlers will be explicitly visible in OpenSim.Server.Handlers. That's one of the major goals for what we're doing here, to have some order / standardization in the code. Looking at that namespace, it will be very clear what it is that OpenSim servers respond to. With ROBUST, the difference between simulator server and other servers is blurred, though. It's up to the people who configure the system to decide which servers load which handlers and the corresponding services. Impalah Shenzhou wrote: Will be only a name change from messaging to presence or some of the rest/xml methods of the messaging server will pass to another server or will dissapear? (for example presence_info_bulk or login_to_simulator) And another question, if anyone knows, is there any UPDATED list (at least for version 0.6.5 and higher) of the public methods published by the ugaim/robust servers or, even better, used by the region servers? The one on the wiki is ld and incomplete. Thanks 2010/1/4 Cristina Videira Lopes lo...@ics.uci.edu mailto:lo...@ics.uci.edu On Jan 4, 2010, at 10:31 AM, Justin Clark-Casey wrote: Could I ask what is being done about the message service? This is still in its pre-ROBUST form and I don't think that we can tag 0.7 without converting this service. Simple: the messaging server will disappear :) It was never a messaging server in the first place. It was a presence server wannabe: it was only there to track the location of agents. Messaging itself is p2p, not centralized. Yeah, another one of the early misnomers that led to generalized confusion :) The IM region module that does the p2p IM-ing will stay more or less unchanged, except that it queries the new presence service instead. Mel and I had a conversation yesterday about making the p2p connectors/ handlers in it explicit and visible out of the Region namespace like all other connectors/handlers, but she convinced me that we shouldn't touch it until we're ready to rewrite it completely. Probably won't happen for 0.7. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de mailto:Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] User services refactoring status
It all changes completely and beyond recognition. Melanie Impalah Shenzhou wrote: Will be only a name change from messaging to presence or some of the rest/xml methods of the messaging server will pass to another server or will dissapear? (for example presence_info_bulk or login_to_simulator) And another question, if anyone knows, is there any UPDATED list (at least for version 0.6.5 and higher) of the public methods published by the ugaim/robust servers or, even better, used by the region servers? The one on the wiki is ld and incomplete. Thanks 2010/1/4 Cristina Videira Lopes lo...@ics.uci.edu On Jan 4, 2010, at 10:31 AM, Justin Clark-Casey wrote: Could I ask what is being done about the message service? This is still in its pre-ROBUST form and I don't think that we can tag 0.7 without converting this service. Simple: the messaging server will disappear :) It was never a messaging server in the first place. It was a presence server wannabe: it was only there to track the location of agents. Messaging itself is p2p, not centralized. Yeah, another one of the early misnomers that led to generalized confusion :) The IM region module that does the p2p IM-ing will stay more or less unchanged, except that it queries the new presence service instead. Mel and I had a conversation yesterday about making the p2p connectors/ handlers in it explicit and visible out of the Region namespace like all other connectors/handlers, but she convinced me that we shouldn't touch it until we're ready to rewrite it completely. Probably won't happen for 0.7. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] User services refactoring status
For serious uses, absolutely I wouldn't recommend SQLite, but put yourselves in the mind of the end user - or even someone wanting to just get up and running with minimum of fuss. Why should I install a database server platform on my machine? It'll be running on startup, eating my resources, it's an extra thing I don't want to care about - I just want to try OpenSim. SQLite is a wonderful quick and simple introduction and it means you can easily carry an OpenSim install on a memory stick with minimum fuss. I would be gutted if SQLite was ditched because no-one cared to update it - I'm already committed to maintaining MSSQL, which I'll happily do, but SQLite needs love too. I have very little time to spare, would love a volunteer to step forward and help out on keeping it alive... I appreciate the point that shipping broken code as part of an application is a terrible idea - only encouraging people to get frustrated and angry that their application doesn't work. But some features need to be fixed, not just ditched - I vote that this is one of them. Chris -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of d...@metaverseink.com Sent: 05 January 2010 3:58 PM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] User services refactoring status I'm neutral about keeping support for SQLite in core. For me, it's all a matter of someone taking the lead on maintaining it. Honestly, I agree with Justin, and that's the reason why I'm not doing that maintenance work myself. Having a no-installation OpenSim is very nice just to make it work and to have a feel for what OpenSim can do, but I think that the particular implementation of that concept -- with SQLite -- is quite deceiving. No one in his/her right mind would use SQLite as the DB for serious uses of OpenSim, just like no one uses it as the backend to web applications (there are always exceptions to every rule, of course!). As such, starting off with SQLite, liking OpenSim, and then discovering that one needs to migrate the data from SQLite to another DB system is not situation that we should induce people into. In order to implement the no-installation concept, which is a good concept, I'd much rather have an in-memory DB layer with no persistence at all. All data would disappear once the sim shuts down. That way it would be very clear to everyone that if they want persistence they need to think and research about which database system works for them. In some rare cases, people may come to the conclusion that SQLite is what works best for them. Those people should take the lead on maintaining the SQLite OpenSim connector. Justin Clark-Casey wrote: Daniel Smith wrote: As a developer of other things, but a user of OpenSim, I would say 'keep sqlite'. Keep the barriers to entry as low as possible. If someone wants to try out OpenSim, make it easy for them. Put your end-user hat on for a moment. I would usually make the same argument and this was why I did feel a preference keeping sqlite. However, on reflection, I'm not sure whether it actually helps that much. OpenSim is always going to be somewhat complicated to set up and run so the added necessity to install a database as well doesn't seem too onerous to me. Mysql is a pretty simple install on all platforms. We also quite often seem to get situations where someone has started off with sqlite and later realizes that they need to convert everything to mysql in order to grow. This can be an awkward process. In addition, we already have a situation where some things are not implemented in sqlite (afaik, attachment persistence still isn't implemented there). It might be better if we don't make the end-user suffer these issues. Anyway, as Diva said, all this really depends on people stepping up to make the necessary code changes for sqlite. If people do then it will remain in the codebase. If nobody does then I think that we may be better off removing it for now. cheers, Daniel On Mon, Jan 4, 2010 at 11:57 AM, Robert Martin robertl...@gmail.com mailto:robertl...@gmail.com wrote: Just adding my thoughts given that XAMP is very easy to setup (heck it would be simple to just have a pre-setup XAMP module as an add-on download) sqlite is not really needed. side question i have a diva install where the DB crashed midway during the first migration stage do i need to dump the tables and start over?? -- Robert L Martin ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de mailto:Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev -- Daniel Smith - Sonoma County, California http://daniel.org/resume
Re: [Opensim-dev] User services refactoring status
Maybe someone can explain why the nhibernate orm isn't focussed on? Wouldn't that make opensim more db independent? Are there issues with it? or? cheers, Jeroen ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] User services refactoring status
NHibernate was removed. It had no maintainer and no users. It was too slow for prim storage. Melanie Jeroen van Veen wrote: Maybe someone can explain why the nhibernate orm isn't focussed on? Wouldn't that make opensim more db independent? Are there issues with it? or? cheers, Jeroen ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] User services refactoring status
Hi, Robert Martin wrote: 1 the base Suite Of what? 2 the upgraded/beta launcher What launcher? 3 Gimp ,Blender and whatever else' How relevant is that for an opensim server? 4 the XAMP launcher 5 XAMP itself What is that for? You have not received any comments on XAMP at all. Maybe people are not familiar with it. I know I'm not. 6 GreenLife Emerald Emerald is not the best for OpenSim. It's very SL specific in many of it's features. 7 DIVA Or a spin of your choice Melanie ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] User services refactoring status
Tom, yes, the Wiredux as it's posted on the Gforge is outdated and won't have a update that will support the new basics. In time, I hope to release a new version of the OpenWiredux that will support the new basics but this will take some more time. 2010/1/5 Tom Willans tom.will...@bessacarr.com Hi, First thanks for all your work. I assume from this that the webredux will no longer work without modification and will need updating. ( Thanks again here). Is there any information about the new authentication approach anywhere, if not in detail then an overview. Is LDAP on the horizon? I am mostly interested in linking php based frontends to opensim and hence accessing the database directly. Particularly relevant is moving away from using UUIDs. Please forgive me if I am missing something but I assume there are no web-services that can be called and calling C# from php is not a very good solution. Thanks. Tom On 5 Jan 2010, at 10:37, Ai Austin wrote: At 18:32 04/01/2010, opensim-dev-requ...@lists.berlios.de wrote: To be honest, I don't think Sqlite should be a database type that we (OpenSim) should keep alive in the project, It is useful to have a double click and go out of the box solution which people can try out and test with. One other use of SQLite that I am aware of and fine very useful is for the really simple and handy single region hosted on your own system that is connected to the New World Grid for any avatar using the New World Studio packaged version of Opensim. See http://www.newworldgrid.com/lang/en-us/land/free-land ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev Tom Willans Managing Director Bessacarr Publications Ltd 3 Highfield, Hatton Park, Warwick, CV35 7TQ tom.will...@bessacarr.com +44 (0) 1926 402055 +44 (0) 121 288 0281 Registered in England and Wales at the above address. Company No: 4925067. VAT No:GB 823 9317 24. This e-mail is confidential and intended solely for the use of the individual to whom it is addressed. Any views or opinions presented are solely those of the author and do not necessarily represent those of Bessacarr Publications Ltd. If you are not the intended recipient you have received this e-mail in error and that any use, dissemination, forwarding, printing or copying of this e-mail is strictly prohibited. Please return it to the sender immediately. The contents of this message may be legally privileged. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] User services refactoring status
Do you expect those formalized interfaces to remain stable long enough to warrant the effort to create alternative implementations? Others have provided alternative implementations in the past that quickly became obsolete. --mic On Tue, Jan 5, 2010 at 2:17 PM, d...@metaverseink.com wrote: Putting PHP in front of the DBs is one of the most natural things to do from here on -- not just the things that Wiredux does, but for a lot more! In fact, the entire collection of OpenSim.Services that are provided as reference implementations can be replaced with implementations in Apache+PHP. Calls from the simulators to the services are now all neatly packaged in OpenSim.Services.Connectors (these are the out connectors). Just browse through those connectors and check out the wire protocols, then do the receiving end in PHP. Many of them are using standard web forms, others use XMLRPC, others use custom-made HTTP-based dialects. Calls from outside to the simulators are packaged in OpenSim.Server.Handlers. Again, check them out and, if not using .NET, write your own client for them. If using .NET/mono you can import the DLL OpenSim.Connectors.dll, and reuse the existing connectors as-is. But that's not all. Since now the interactions between the simulators and the resource services are all formalized in interfaces (OpenSim.Services.Interfaces), and the handlers and connectors in the simulator are loaded dynamically, you can replace the connectors and handlers themselves. In other words, if you want OpenSim to talk web services, roll your own Web Services handlers and connectors under those interfaces, and you're done -- you'll have to use .NET for this part, though. Tom Willans wrote: Hi, First thanks for all your work. I assume from this that the webredux will no longer work without modification and will need updating. ( Thanks again here). Is there any information about the new authentication approach anywhere, if not in detail then an overview. Is LDAP on the horizon? I am mostly interested in linking php based frontends to opensim and hence accessing the database directly. Particularly relevant is moving away from using UUIDs. Please forgive me if I am missing something but I assume there are no web-services that can be called and calling C# from php is not a very good solution. Thanks. Tom On 5 Jan 2010, at 10:37, Ai Austin wrote: At 18:32 04/01/2010, opensim-dev-requ...@lists.berlios.de mailto:opensim-dev-requ...@lists.berlios.de wrote: To be honest, I don't think Sqlite should be a database type that we (OpenSim) should keep alive in the project, It is useful to have a double click and go out of the box solution which people can try out and test with. One other use of SQLite that I am aware of and fine very useful is for the really simple and handy single region hosted on your own system that is connected to the New World Grid for any avatar using the New World Studio packaged version of Opensim. See http://www.newworldgrid.com/lang/en-us/land/free-land ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de mailto:Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev Tom Willans Managing Director Bessacarr Publications Ltd 3 Highfield, Hatton Park, Warwick, CV35 7TQ tom.will...@bessacarr.com mailto:tom.will...@bessacarr.com +44 (0) 1926 402055 +44 (0) 121 288 0281 Registered in England and Wales at the above address. Company No: 4925067. VAT No:GB 823 9317 24. This e-mail is confidential and intended solely for the use of the individual to whom it is addressed. Any views or opinions presented are solely those of the author and do not necessarily represent those of Bessacarr Publications Ltd. If you are not the intended recipient you have received this e-mail in error and that any use, dissemination, forwarding, printing or copying of this e-mail is strictly prohibited. Please return it to the sender immediately. The contents of this message may be legally privileged. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] User services refactoring status
In my experience, no project is, or should be, 'stable' until it reaches 1.0. Before 1.0 people programming against the core code do it at their own peril, and should not complain. It's completely unrealistic to demand interface stability during early stages, and it's actually quite harmful -- stabilizing on bad design is the worst that can happen to a project. Even after 1.0, interfaces change. Just to point one among many examples that I know first hand: Apache Lucene, changed dramatically from 1.x to 2.0. So I'm not sure what to tell you. Will the interfaces change? Most likely. Will the pace of changes slow down over time? Definitely. When is a good time for people to extend OpenSim 'safely'? Not before 1.0. Mic Bowman wrote: Do you expect those formalized interfaces to remain stable long enough to warrant the effort to create alternative implementations? Others have provided alternative implementations in the past that quickly became obsolete. --mic On Tue, Jan 5, 2010 at 2:17 PM, d...@metaverseink.com mailto:d...@metaverseink.com wrote: Putting PHP in front of the DBs is one of the most natural things to do from here on -- not just the things that Wiredux does, but for a lot more! In fact, the entire collection of OpenSim.Services that are provided as reference implementations can be replaced with implementations in Apache+PHP. Calls from the simulators to the services are now all neatly packaged in OpenSim.Services.Connectors (these are the out connectors). Just browse through those connectors and check out the wire protocols, then do the receiving end in PHP. Many of them are using standard web forms, others use XMLRPC, others use custom-made HTTP-based dialects. Calls from outside to the simulators are packaged in OpenSim.Server.Handlers. Again, check them out and, if not using .NET, write your own client for them. If using .NET/mono you can import the DLL OpenSim.Connectors.dll, and reuse the existing connectors as-is. But that's not all. Since now the interactions between the simulators and the resource services are all formalized in interfaces (OpenSim.Services.Interfaces), and the handlers and connectors in the simulator are loaded dynamically, you can replace the connectors and handlers themselves. In other words, if you want OpenSim to talk web services, roll your own Web Services handlers and connectors under those interfaces, and you're done -- you'll have to use .NET for this part, though. Tom Willans wrote: Hi, First thanks for all your work. I assume from this that the webredux will no longer work without modification and will need updating. ( Thanks again here). Is there any information about the new authentication approach anywhere, if not in detail then an overview. Is LDAP on the horizon? I am mostly interested in linking php based frontends to opensim and hence accessing the database directly. Particularly relevant is moving away from using UUIDs. Please forgive me if I am missing something but I assume there are no web-services that can be called and calling C# from php is not a very good solution. Thanks. Tom On 5 Jan 2010, at 10:37, Ai Austin wrote: At 18:32 04/01/2010, opensim-dev-requ...@lists.berlios.de mailto:opensim-dev-requ...@lists.berlios.de mailto:opensim-dev-requ...@lists.berlios.de mailto:opensim-dev-requ...@lists.berlios.de wrote: To be honest, I don't think Sqlite should be a database type that we (OpenSim) should keep alive in the project, It is useful to have a double click and go out of the box solution which people can try out and test with. One other use of SQLite that I am aware of and fine very useful is for the really simple and handy single region hosted on your own system that is connected to the New World Grid for any avatar using the New World Studio packaged version of Opensim. See http://www.newworldgrid.com/lang/en-us/land/free-land ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de mailto:Opensim-dev@lists.berlios.de mailto:Opensim-dev@lists.berlios.de mailto:Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev Tom Willans Managing Director Bessacarr Publications Ltd 3 Highfield, Hatton Park, Warwick, CV35 7TQ tom.will...@bessacarr.com mailto:tom.will...@bessacarr.com mailto:tom.will...@bessacarr.com mailto:tom.will...@bessacarr.com +44 (0) 1926 402055 +44 (0) 121 288 0281 Registered in England and Wales at the above address. Company No:
Re: [Opensim-dev] User services refactoring status
I'd have to say...comparing the removel of NHibernate because the interface went neglected over months... to dropping SQL lite becasue no one has jumped forward to volunteer for an unknown amount of work seems a bit out of place.The refactor of services may have been complete for days, and the scope of the DB changes have to be identified before anyone ( except the folks who did the MySQL work) would rationally jump up and say yes. The argument that IT DOESNT work with the latest versions of mono is meaningless if I want to pick a version of mono that the connectors do work with The ability to crank up a release of opensim on a production machine to test it with limited (non-production) DB is VERY useful for debugging possible causes of configuration failures... and from a Marketing perspective.. a simple works out of the box demo is one of the more important tools you can put in the hands of the users you want to come flocking to build on your platform... We aren't ripping any other features out that people don't want to fix/maintainwhy is SQLite different? On Tue, Jan 5, 2010 at 2:43 PM, Mic Bowman cmick...@gmail.com wrote: Do you expect those formalized interfaces to remain stable long enough to warrant the effort to create alternative implementations? Others have provided alternative implementations in the past that quickly became obsolete. --mic On Tue, Jan 5, 2010 at 2:17 PM, d...@metaverseink.com wrote: Putting PHP in front of the DBs is one of the most natural things to do from here on -- not just the things that Wiredux does, but for a lot more! In fact, the entire collection of OpenSim.Services that are provided as reference implementations can be replaced with implementations in Apache+PHP. Calls from the simulators to the services are now all neatly packaged in OpenSim.Services.Connectors (these are the out connectors). Just browse through those connectors and check out the wire protocols, then do the receiving end in PHP. Many of them are using standard web forms, others use XMLRPC, others use custom-made HTTP-based dialects. Calls from outside to the simulators are packaged in OpenSim.Server.Handlers. Again, check them out and, if not using .NET, write your own client for them. If using .NET/mono you can import the DLL OpenSim.Connectors.dll, and reuse the existing connectors as-is. But that's not all. Since now the interactions between the simulators and the resource services are all formalized in interfaces (OpenSim.Services.Interfaces), and the handlers and connectors in the simulator are loaded dynamically, you can replace the connectors and handlers themselves. In other words, if you want OpenSim to talk web services, roll your own Web Services handlers and connectors under those interfaces, and you're done -- you'll have to use .NET for this part, though. Tom Willans wrote: Hi, First thanks for all your work. I assume from this that the webredux will no longer work without modification and will need updating. ( Thanks again here). Is there any information about the new authentication approach anywhere, if not in detail then an overview. Is LDAP on the horizon? I am mostly interested in linking php based frontends to opensim and hence accessing the database directly. Particularly relevant is moving away from using UUIDs. Please forgive me if I am missing something but I assume there are no web-services that can be called and calling C# from php is not a very good solution. Thanks. Tom On 5 Jan 2010, at 10:37, Ai Austin wrote: At 18:32 04/01/2010, opensim-dev-requ...@lists.berlios.de mailto:opensim-dev-requ...@lists.berlios.de wrote: To be honest, I don't think Sqlite should be a database type that we (OpenSim) should keep alive in the project, It is useful to have a double click and go out of the box solution which people can try out and test with. One other use of SQLite that I am aware of and fine very useful is for the really simple and handy single region hosted on your own system that is connected to the New World Grid for any avatar using the New World Studio packaged version of Opensim. See http://www.newworldgrid.com/lang/en-us/land/free-land ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de mailto:Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev Tom Willans Managing Director Bessacarr Publications Ltd 3 Highfield, Hatton Park, Warwick, CV35 7TQ tom.will...@bessacarr.com mailto:tom.will...@bessacarr.com +44 (0) 1926 402055 +44 (0) 121 288 0281 Registered in England and Wales at the above address. Company No: 4925067. VAT No:GB 823 9317 24. This e-mail is confidential and intended solely for the use of the individual to whom it is addressed. Any views or opinions presented are solely those of the author and do not
Re: [Opensim-dev] User services refactoring status
On Mon, Jan 4, 2010 at 6:02 PM, d...@metaverseink.com wrote: Hi everyone, Just an quick message to let you know about the status of the refactoring, and to ask for help in some parts. Between Christmas and now, Melanie and I have re-engineered the way that OpenSim handles users, agents, and avatars, and the persistent data associated with all of these. This is the final push on the refactoring (and improvement) work that started back in May. This last piece of the work is being done in the branch presence-refactor. There are several new services that correspond to breaking up the user server into smaller pieces, i.e. things that the user server already did but in very awkward manner. Namely: user accounts (it's just that, accounts), authentication (manages passwords, auth tokens and the like), presence (knows where agents are), avatar (manages the 'carcass') and friends (social net basics). All of these have been made fairly generic, and this will enable a whole new level of extending OpenSim. For example, strings are used in important identifiers instead of UUIDs. Additionally, what was previously known as Interregion Comms (Local and REST) is now a simulation service provided by the sims. This last service makes agent transfers consistent throughout their existence -- login and TPs -- and allows for future alternative ways of driving agents. ETA on merging this with master branch is next weekend. I think we're on track to have OpenSim 0.7 sometime in January. This will also allow us to start taking security seriously right after 0.7 is tagged. I encourage you to check out the branch and, at least, look through OpenSim.Services.Interfaces, which now tell the story quite well. The really brave can try it out on test grids/standalones. (Please use test grids/DBs only for the time being!) Notice the configuration files which now have a lot more in them. NOTE: only works for MySQL at the moment. This leads me to the asking-for-help part. The DB schema has changed substantially. We have been doing this with MySql. We need help to make the same changes to SQLite and MSSQL, if these are to be supported from here on. I know we can count on StrawberryFride to update the MSSQL connector. However, for SQLite... it has been falling through the cracks. There is already a show-stopper bug in it that makes the SQLite connector not work with mono 2.4.3 and higher (http://opensimulator.org/mantis/view.php?id=4463). Unless someone steps in and takes care of the SQLite connector, I'm afraid it will go the way of the dinosaurs. Thanks! Diva / Canto Excellent work Mel and Diva! The next step in making OS _the_ platform for novel VW applications. Cheers, ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] User services refactoring status
Ryan McDougall wrote: Excellent work Mel and Diva! The next step in making OS _the_ platform for novel VW applications. Isn't it already?? :) Melanie ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] User services refactoring status
Diva, To be honest, I don't think Sqlite should be a database type that we (OpenSim) should keep alive in the project, Setting up a simple MySQL server is made easier these days with products like Xampp and others. I would call for a vote to exclude Sqlite from the code. At this moment, the most working Opensim database implementations are MySQL and MSSQL Nhibernate can be used for any of the other database servers that exists (but i know that there's no one maintaining Nhibernate) 2010/1/4 d...@metaverseink.com Hi everyone, Just an quick message to let you know about the status of the refactoring, and to ask for help in some parts. Between Christmas and now, Melanie and I have re-engineered the way that OpenSim handles users, agents, and avatars, and the persistent data associated with all of these. This is the final push on the refactoring (and improvement) work that started back in May. This last piece of the work is being done in the branch presence-refactor. There are several new services that correspond to breaking up the user server into smaller pieces, i.e. things that the user server already did but in very awkward manner. Namely: user accounts (it's just that, accounts), authentication (manages passwords, auth tokens and the like), presence (knows where agents are), avatar (manages the 'carcass') and friends (social net basics). All of these have been made fairly generic, and this will enable a whole new level of extending OpenSim. For example, strings are used in important identifiers instead of UUIDs. Additionally, what was previously known as Interregion Comms (Local and REST) is now a simulation service provided by the sims. This last service makes agent transfers consistent throughout their existence -- login and TPs -- and allows for future alternative ways of driving agents. ETA on merging this with master branch is next weekend. I think we're on track to have OpenSim 0.7 sometime in January. This will also allow us to start taking security seriously right after 0.7 is tagged. I encourage you to check out the branch and, at least, look through OpenSim.Services.Interfaces, which now tell the story quite well. The really brave can try it out on test grids/standalones. (Please use test grids/DBs only for the time being!) Notice the configuration files which now have a lot more in them. NOTE: only works for MySQL at the moment. This leads me to the asking-for-help part. The DB schema has changed substantially. We have been doing this with MySql. We need help to make the same changes to SQLite and MSSQL, if these are to be supported from here on. I know we can count on StrawberryFride to update the MSSQL connector. However, for SQLite... it has been falling through the cracks. There is already a show-stopper bug in it that makes the SQLite connector not work with mono 2.4.3 and higher (http://opensimulator.org/mantis/view.php?id=4463). Unless someone steps in and takes care of the SQLite connector, I'm afraid it will go the way of the dinosaurs. Thanks! Diva / Canto ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] User services refactoring status
d...@metaverseink.com wrote: ETA on merging this with master branch is next weekend. I think we're on track to have OpenSim 0.7 sometime in January. This will also allow us to start taking security seriously right after 0.7 is tagged. Thanks for the update. Diva. I would like to see at least a 2 week gap after the work is in master before creating a 0.7.0-post-fixes branch. As there's going to be some code upheaval shortly afterwards I think we should try to ensure that 0.7 isn't any worse than our previous releases. This would mean that actually tagging 0.7 would follow some time after the branch to allow for some degree of testing. Could I ask what is being done about the message service? This is still in its pre-ROBUST form and I don't think that we can tag 0.7 without converting this service. I encourage you to check out the branch and, at least, look through OpenSim.Services.Interfaces, which now tell the story quite well. The really brave can try it out on test grids/standalones. (Please use test grids/DBs only for the time being!) Notice the configuration files which now have a lot more in them. NOTE: only works for MySQL at the moment. This leads me to the asking-for-help part. The DB schema has changed substantially. We have been doing this with MySql. We need help to make the same changes to SQLite and MSSQL, if these are to be supported from here on. I know we can count on StrawberryFride to update the MSSQL connector. However, for SQLite... it has been falling through the cracks. There is already a show-stopper bug in it that makes the SQLite connector not work with mono 2.4.3 and higher (http://opensimulator.org/mantis/view.php?id=4463). Unless someone steps in and takes care of the SQLite connector, I'm afraid it will go the way of the dinosaurs. I have a preference for retaining sqlite but unfortunately I don't have the time to fix it up. If no one can step up then maybe it has to be put into deep freeze. Regards, -- Justin Clark-Casey (justincc) http://justincc.org http://twitter.com/justincc ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] User services refactoring status
On Mon, Jan 4, 2010 at 7:26 PM, Melanie mela...@t-data.com wrote: Ryan McDougall wrote: Excellent work Mel and Diva! The next step in making OS _the_ platform for novel VW applications. Isn't it already?? :) When the new scene graph work gets done. :) ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] User services refactoring status
Just adding my thoughts given that XAMP is very easy to setup (heck it would be simple to just have a pre-setup XAMP module as an add-on download) sqlite is not really needed. side question i have a diva install where the DB crashed midway during the first migration stage do i need to dump the tables and start over?? -- Robert L Martin ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] User services refactoring status
As a developer of other things, but a user of OpenSim, I would say 'keep sqlite'. Keep the barriers to entry as low as possible. If someone wants to try out OpenSim, make it easy for them. Put your end-user hat on for a moment. cheers, Daniel On Mon, Jan 4, 2010 at 11:57 AM, Robert Martin robertl...@gmail.com wrote: Just adding my thoughts given that XAMP is very easy to setup (heck it would be simple to just have a pre-setup XAMP module as an add-on download) sqlite is not really needed. side question i have a diva install where the DB crashed midway during the first migration stage do i need to dump the tables and start over?? -- Robert L Martin ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev -- Daniel Smith - Sonoma County, California http://daniel.org/resume ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] User services refactoring status
This is not a keep it / kill it discussion. The SQLite connector is there. This is about someone stepping up to do the required improvement work. Neither Mel nor I nor Justin will do it. If no one does it, that connector will be outdated and unusable -- that's the definition of 'dead code'. Dead code will be removed. This happened to the NHibernate connector already the last time we changed the DB schema. So if someone cares for OpenSim+SQLite, now is the time to put your love into code to the benefit of all. If no one cares, it will die. On Jan 4, 2010, at 12:11 PM, Daniel Smith wrote: As a developer of other things, but a user of OpenSim, I would say 'keep sqlite'. Keep the barriers to entry as low as possible. If someone wants to try out OpenSim, make it easy for them. Put your end-user hat on for a moment. cheers, Daniel On Mon, Jan 4, 2010 at 11:57 AM, Robert Martin robertl...@gmail.com wrote: Just adding my thoughts given that XAMP is very easy to setup (heck it would be simple to just have a pre-setup XAMP module as an add-on download) sqlite is not really needed. side question i have a diva install where the DB crashed midway during the first migration stage do i need to dump the tables and start over?? -- Robert L Martin ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev -- Daniel Smith - Sonoma County, California http://daniel.org/resume ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] User services refactoring status
Heck, I don't even have a single box left with Mono old enough to run SQlite. Melanie Cristina Videira Lopes wrote: This is not a keep it / kill it discussion. The SQLite connector is there. This is about someone stepping up to do the required improvement work. Neither Mel nor I nor Justin will do it. If no one does it, that connector will be outdated and unusable -- that's the definition of 'dead code'. Dead code will be removed. This happened to the NHibernate connector already the last time we changed the DB schema. So if someone cares for OpenSim+SQLite, now is the time to put your love into code to the benefit of all. If no one cares, it will die. On Jan 4, 2010, at 12:11 PM, Daniel Smith wrote: As a developer of other things, but a user of OpenSim, I would say 'keep sqlite'. Keep the barriers to entry as low as possible. If someone wants to try out OpenSim, make it easy for them. Put your end-user hat on for a moment. cheers, Daniel On Mon, Jan 4, 2010 at 11:57 AM, Robert Martin robertl...@gmail.com wrote: Just adding my thoughts given that XAMP is very easy to setup (heck it would be simple to just have a pre-setup XAMP module as an add-on download) sqlite is not really needed. side question i have a diva install where the DB crashed midway during the first migration stage do i need to dump the tables and start over?? -- Robert L Martin ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev -- Daniel Smith - Sonoma County, California http://daniel.org/resume ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] User services refactoring status
I have a lot of the newest .NET implementations that use sqlite :) I thought we agreed to make the necessary changes to all of the current supported database adapters or /secure support/ on doing that /before/ we make the changes *not after* that outdate one of them. Apparently you don't subscribe to this. Regards Teravus On Mon, Jan 4, 2010 at 3:39 PM, Melanie mela...@t-data.com wrote: Heck, I don't even have a single box left with Mono old enough to run SQlite. Melanie Cristina Videira Lopes wrote: This is not a keep it / kill it discussion. The SQLite connector is there. This is about someone stepping up to do the required improvement work. Neither Mel nor I nor Justin will do it. If no one does it, that connector will be outdated and unusable -- that's the definition of 'dead code'. Dead code will be removed. This happened to the NHibernate connector already the last time we changed the DB schema. So if someone cares for OpenSim+SQLite, now is the time to put your love into code to the benefit of all. If no one cares, it will die. On Jan 4, 2010, at 12:11 PM, Daniel Smith wrote: As a developer of other things, but a user of OpenSim, I would say 'keep sqlite'. Keep the barriers to entry as low as possible. If someone wants to try out OpenSim, make it easy for them. Put your end-user hat on for a moment. cheers, Daniel On Mon, Jan 4, 2010 at 11:57 AM, Robert Martin robertl...@gmail.com wrote: Just adding my thoughts given that XAMP is very easy to setup (heck it would be simple to just have a pre-setup XAMP module as an add-on download) sqlite is not really needed. side question i have a diva install where the DB crashed midway during the first migration stage do i need to dump the tables and start over?? -- Robert L Martin ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev -- Daniel Smith - Sonoma County, California http://daniel.org/resume ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] User services refactoring status
On Jan 4, 2010, at 10:31 AM, Justin Clark-Casey wrote: Could I ask what is being done about the message service? This is still in its pre-ROBUST form and I don't think that we can tag 0.7 without converting this service. Simple: the messaging server will disappear :) It was never a messaging server in the first place. It was a presence server wannabe: it was only there to track the location of agents. Messaging itself is p2p, not centralized. Yeah, another one of the early misnomers that led to generalized confusion :) The IM region module that does the p2p IM-ing will stay more or less unchanged, except that it queries the new presence service instead. Mel and I had a conversation yesterday about making the p2p connectors/ handlers in it explicit and visible out of the Region namespace like all other connectors/handlers, but she convinced me that we shouldn't touch it until we're ready to rewrite it completely. Probably won't happen for 0.7. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] User services refactoring status
The merge will happen whether or not sqlite is updated, right? There seems to be an estimated date for it. How can there be an estimated date for the merge unless there is someone secured to work on sqlite.. unless you intend to go on with it anyway? Teravus On Mon, Jan 4, 2010 at 3:53 PM, Melanie mela...@t-data.com wrote: That doesn't apply to work in branches. Diva IS looking for support for SQLite here _before_ the merge, right? Melanie Teravus Ovares wrote: I have a lot of the newest .NET implementations that use sqlite :) I thought we agreed to make the necessary changes to all of the current supported database adapters or /secure support/ on doing that /before/ we make the changes *not after* that outdate one of them. Apparently you don't subscribe to this. Regards Teravus On Mon, Jan 4, 2010 at 3:39 PM, Melanie mela...@t-data.com wrote: Heck, I don't even have a single box left with Mono old enough to run SQlite. Melanie Cristina Videira Lopes wrote: This is not a keep it / kill it discussion. The SQLite connector is there. This is about someone stepping up to do the required improvement work. Neither Mel nor I nor Justin will do it. If no one does it, that connector will be outdated and unusable -- that's the definition of 'dead code'. Dead code will be removed. This happened to the NHibernate connector already the last time we changed the DB schema. So if someone cares for OpenSim+SQLite, now is the time to put your love into code to the benefit of all. If no one cares, it will die. On Jan 4, 2010, at 12:11 PM, Daniel Smith wrote: As a developer of other things, but a user of OpenSim, I would say 'keep sqlite'. Keep the barriers to entry as low as possible. If someone wants to try out OpenSim, make it easy for them. Put your end-user hat on for a moment. cheers, Daniel On Mon, Jan 4, 2010 at 11:57 AM, Robert Martin robertl...@gmail.com wrote: Just adding my thoughts given that XAMP is very easy to setup (heck it would be simple to just have a pre-setup XAMP module as an add-on download) sqlite is not really needed. side question i have a diva install where the DB crashed midway during the first migration stage do i need to dump the tables and start over?? -- Robert L Martin ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev -- Daniel Smith - Sonoma County, California http://daniel.org/resume ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] User services refactoring status
As it stands right now, SQLite is not usable or testable: http://opensimulator.org/mantis/view.php?id=4437 I don't think it's reasonable to expect that one or two developers do the maintenance on *all* alternative implementations of things. Hence this request for help. Nothing has been merged to master yet, so this is, effectively, /before/. I know the MSSQL connector will be covered. I don't know about the SQLite connector. If no one steps up to the job, what it means is that no one cares enough to allocate their own time to maintain it. We cannot stop evolving / improving OpenSim entirely because of lack of interest on one of three alternative DB connectors... NHibernate was removed, because no one cared for it enough to maintain it. The same will happen to SQLite if no one steps up. As for estimate -- that's what it is, an estimate, not a definitive date. We have a process here. If you give a -1 to the merge on the grounds that SQLite support has not been secured, then the merge will not happen. Simple :) On Jan 4, 2010, at 12:57 PM, Teravus Ovares wrote: The merge will happen whether or not sqlite is updated, right? There seems to be an estimated date for it. How can there be an estimated date for the merge unless there is someone secured to work on sqlite.. unless you intend to go on with it anyway? Teravus On Mon, Jan 4, 2010 at 3:53 PM, Melanie mela...@t-data.com wrote: That doesn't apply to work in branches. Diva IS looking for support for SQLite here _before_ the merge, right? Melanie Teravus Ovares wrote: I have a lot of the newest .NET implementations that use sqlite :) I thought we agreed to make the necessary changes to all of the current supported database adapters or /secure support/ on doing that /before/ we make the changes *not after* that outdate one of them. Apparently you don't subscribe to this. Regards Teravus On Mon, Jan 4, 2010 at 3:39 PM, Melanie mela...@t-data.com wrote: Heck, I don't even have a single box left with Mono old enough to run SQlite. Melanie Cristina Videira Lopes wrote: This is not a keep it / kill it discussion. The SQLite connector is there. This is about someone stepping up to do the required improvement work. Neither Mel nor I nor Justin will do it. If no one does it, that connector will be outdated and unusable -- that's the definition of 'dead code'. Dead code will be removed. This happened to the NHibernate connector already the last time we changed the DB schema. So if someone cares for OpenSim+SQLite, now is the time to put your love into code to the benefit of all. If no one cares, it will die. On Jan 4, 2010, at 12:11 PM, Daniel Smith wrote: As a developer of other things, but a user of OpenSim, I would say 'keep sqlite'. Keep the barriers to entry as low as possible. If someone wants to try out OpenSim, make it easy for them. Put your end-user hat on for a moment. cheers, Daniel On Mon, Jan 4, 2010 at 11:57 AM, Robert Martin robertl...@gmail.com wrote: Just adding my thoughts given that XAMP is very easy to setup (heck it would be simple to just have a pre-setup XAMP module as an add-on download) sqlite is not really needed. side question i have a diva install where the DB crashed midway during the first migration stage do i need to dump the tables and start over?? -- Robert L Martin ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev -- Daniel Smith - Sonoma County, California http://daniel.org/resume ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] User services refactoring status
Just as a proof of concept i am in the middle of uploading a pre-setup copy of XAMP to my website at http://www.laurencemartin.org/opensim/divaxamp.zip to use Unzip run the xampsetup.bat (to relink the paths) and then proceed to the diva setup (password is shadow) as long as the hooks to re-add sqlite support are left in place i would say FOR THE TIME BEING drop the code out (or mark ti as being borken) -- Robert L Martin ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
