[Opensim-dev] Roadmap
Stefan Andersson
stefan at tribalmedia.se
Sat Mar 22 11:55:31 UTC 2008
Ditto on the frustration, man. But:
We have three venues, in falling order of complexity:
* Refactor together the existing copy + pasted code
* Implement a lightweight mapper layer (à la the suggested Data Framework)
* Implement a heavy-weight mapper layer (NHibernate)
What we do know, no matter what venue we choose, is that:
* We should keep our data store plug-in interfaces (IGridData, IRegionDataStore ) as our own abstraction of a provider layer. We might change those, but we should have them there.
Now, I don't know much about the central wins of NHibernate, but I do know that whatever we can get from NHibernate, we must make sure we can get from somewhere else too.
This means, basically, that there is no need for the current stand-still;
we can work along all three venues, because all three venues has their pros and cons.
The big win right now isn't getting nhibernate up; that one will take a long while to get stable + usable; the big win would be to refactor the existing code into a set of superclasses - One babystep at a time.
The Data Framework was meant as a suggestion at a time where we didn't know if we could get NHibernate up and running at all; it works well for MW and me (Tribal Media bases all its db coding on it, and we like it) but it's not a goal in itself.
So, I see a path forward where we work with the existing code first, and in _parallell_ get nhibernate in place; then, either nhibernate works well for all scenarios, or we take our own codebase further (possibly by doing the leap to the Data Framework, which should be rather easy if we've done that first refactoring I talked about - since the Framework is really what that refactoring would lead to in the end)
/Stefan
> From: brianw at terrabox.com
> To: opensim-dev at lists.berlios.de
> Date: Fri, 21 Mar 2008 14:52:04 -0500
> Subject: Re: [Opensim-dev] Roadmap
>
> I have a problem. It's called frustration. First, I spent time fixing
> MySQL plugin. Then time on getting MSSQL and SQLite up to MySQL feature
> level. Then I hear about the great replacement for this mess called
> TribalMedia SQLMapper. So I start investigating and poking. Then I hear
> about nHibernate. Then all goes quiet. SO I chat with devs and decide to
> spend time on SQLMapper so we can get out of the multi-SQL hell that
> we're in. Then out of the blue, nHibernate is on the roadmap. ARGH!!!!!
> Someone PLEASE SHOOT ME!
>
> End result... I'm frustrated. I'm irritated. My regions STILL aren't
> stable in the SQL Layer from version to version. I've invested near full
> time for a month now in learning the SQL plugins and fixing things up.
> I've thrown out many patches because the code base moves too damn
> quickly while patches sit unused/tested/integrated. I've put off several
> new features because of this instability/uncertainty. I've halted work
> on HeartBeat. I've halted SQL plugin fixups. I've halted SQLMapper. I
> feel like I've acomplished little more than a few minor bug fixes for
> the many hours of work.
>
> "don't break SQL" is what i've been told many times. Well, SQL is BROKE.
> Has been. Will be until the OpenSim developers decide what it's going to
> be for the forseable future. Yes, the core decides. No the core doesn't
> have the time. Yes the core wants patches for bugs and features. that
> side of the issue is beign addressed.
>
>
> So. In the interest of getting some much needed answers so I can
> actually contribute more than a few fixes and minor features...
>
> Answer me these riddles three!
>
> Is nHibernate really what we need for OpenSim?
>
> What about finishing off the SQLMapper donated by TribalMedia?
>
> Is there a lighter weight SQL abstractor that doesn't complicate the
> build process like nHibernate does and has the necessary features so we
> can just get something in and stable?
>
>
> Personally I'm concerned about nHibernate. Everything that I've heard
> about it in the past is that it's a PITA to use. It's huge and far more
> than most projects need. Granted, I personally have never used
> nHibernate, so this may all be completely wrong information.
>
>
> I like the simplicity within the SQLMapper from TribalMedia. I've
> already invested time in turning it into a storage plugin for
> GridServer. I've added semi-complex WHERE statement handling to it, as
> well as arbitrary single column based selecting. I love that it doesn't
> need 2 stage compiling.
>
> On a realted note, I think it would be a mistake to pull the ability to
> have storage plugins. I don't like the idea of having to learn the vodoo
> magic of nHibernate in order to use backends that nHibernate doesn't
> already support.
>
> sdague informed me in irc (my apologies if I misread) that we would
> still have the ability to load plugins, just not multiple. That's fine
> if we keep the current interface based setup and just eliminate the
> multiple support. :) I could write a multiplexer for when I need to
> funnel writes off in a second direction, to somethign like a search db,
> or a seperate presence system, or a magical flaming cow bot that updates
> an in world map of regions online ;). So, please, don't toss the various
> storage Interface classes like was done with appearance persistence. It
> would be a huge mistake to loose that flexibility IMHO.
>
> ok, enough ranting. For now, i'm stepping back from patching or working
> on OpenSim until the core works out the roadmap and picks a friggin
> storage system to chase. Once things are mapped, i'll dive back in to
> help get it done as quickly as possible.
>
>
> p.s. if I piss off anyone, or mistunderstood anything, please forgive
> me. I'm poor. I'm stressed to hell and back. I've spent valuable time on
> our future and seen it achieve little. Gimme a prozac or a bullet!
>
>
> On Fri, 2008-03-21 at 08:49 -0700, Charles Krinke wrote:
> > As we head towards an OpenSim 0.6 release, hopefully in about 6-8
> > weeks from where we are now, which is 0.5.4, it seems to me that we
> > have a chance to make a couple of minor snapshot releases and then
> > 0.6.
> >
> > Recent thoughts indicate that the following releases on roughly two
> > week intervals might be appropriate. That is, 0.5.6, 0.5.8 and then
> > 0.6.
> >
> > Our 0.6 Roadmap (proposed) at http://opensimulator.org/wiki/Roadmap
> > has:
> >
> >
> > 0.6 Proposed
> > * Database
> > * NHibernate (if possible. This unifies a lot of the
> > data paths and there is some sample NHibernate code on
> > the list)
> > * Persistance for AV Appear across Sim Reboots (partial
> > implementation by MW already)
> > * Scripting
> > * Complete LSL functions (~ 30% now)
> > * Script engine base improvements
> > * Grid Mode
> > * OGS2 REST protocol (we've been kicking this around for
> > a while, perhaps 0.6 is the right time for it?)
> > * Physics
> > * Hollow and Cut Prims support (need to write for 20
> > prim types)
> > * Canned Assets
> > * Clothes
> > * Bodies
> > * Prim Objects
> > * Animations
> > * Textures
> > * Profile
> > * Would like to write a Profile Module interface that
> > lets you backend the profile pane to various different
> > directory services (sdague)
> > So, I guess the questions for the group are:
> >
> > 1. Does this represent out perception of where we wish to be for the
> > 0.6 release?
> > 2. Are two minor snapshot releases of 0.5.6 & 0.5.8 followed by 0.6
> > reasonable?
> > 3. Is merely increasing the time between the snapshots (if desired by
> > core) sufficient for us to get to 0.6 without undue angst?
> >
> > Yours Truly, Don Quixote
> > Trusty Steed, Trusty Lance, Pesky Windmills.
> >
> >
> >
> > _______________________________________________
> > Opensim-dev mailing list
> > Opensim-dev at lists.berlios.de
> > https://lists.berlios.de/mailman/listinfo/opensim-dev
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20080322/5f8e3a1b/attachment-0001.html>
More information about the Opensim-dev
mailing list