[MOO-Cows] Re: forked moo servers
On 9-Dec-04, at 12:09 AM, Gavin Lambert wrote: That was fixed (in the patch, not necesarily on particular servers) fairly quickly though -- at least if you're talking about the same hole that I reported. It wouldn't have been much of a problem except that some of the core security code wasn't all that well-written :) I believe Neil is referring to the fact that WAIFs act like MOO objects, but without many of the constraints one would expect of them. On MOO Canada, we have offload a lot of responsibility to objects under the assumption that they will obey certain rules - a wizard owned property on a base object cannot be modified without going through code to do so, for example. We also employ the -o_verbs patch to make some verbs final (in Java-terminology) on base objects. Taken together, any object that is not bound by these constraints poses a major security problem. To address these issues, we created special syntax for accessing waif properties and methods. A waif object has to be used with an arrow pointer, like 'x-property', or 'x-method()'. Any attempt to use a waif where an object was expected would raise E_TYPE. As a result, code had to be explicitly written to accept waif arguments, or else it was assumed to be insecure. It was argued back and forth whether this removes a significant chunk of waif usefulness, but ultimately waifs were left as a useful tool for specific programming challenges - where you need to store state and have methods of manipulating it, but you don't need a physical object that needs to be interacted with by users. Since this is really the point of waifs, and this functionality was intact, everyone lived happily ever after. -- Mathieu Fenniak [EMAIL PROTECTED] http://stompstompstomp.com/ # This message is sent to you because you are subscribed to the mailing list [EMAIL PROTECTED]. To unsubscribe, E-mail to: [EMAIL PROTECTED] To switch to the DIGEST mode, E-mail to [EMAIL PROTECTED] To switch to the INDEX mode, E-mail to [EMAIL PROTECTED] Send administrative queries to [EMAIL PROTECTED]
[MOO-Cows] Re: forked moo servers
At 3:29 PM -0800 12/6/04, H. Peter Anvin wrote: Daniel Jung wrote: We are about to release a new enCore version soon. It will be unicode, so we converted the database/server to unicode as well. How about this for a strawman: would anyone on this list object to calling LukeJr's GammaMOO LambdaMOO 2.0, assuming ... Btw, where is GammaMOO these days? I'll also note there was the EmeraldMOO project, which was another fork off of LambdaMOO. I think several of these forks start with the best of intentions, but then they don't build enough of a developer community around them, so they fade away. That is a big hurdle for anyone who wants to start on LambdaMOO 2.0, too. I could list all kinds of things that somebody should do as a new version, but I have so many other projects I am busy on that I probably wouldn't contribute much to this one. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] # This message is sent to you because you are subscribed to the mailing list [EMAIL PROTECTED]. To unsubscribe, E-mail to: [EMAIL PROTECTED] To switch to the DIGEST mode, E-mail to [EMAIL PROTECTED] To switch to the INDEX mode, E-mail to [EMAIL PROTECTED] Send administrative queries to [EMAIL PROTECTED]
[MOO-Cows] Re: forked moo servers
There are still another few things I could wish we could incorporate into a possible new lamdaMOO release. I wonder if we could compute a list of changes that have been done in the various versions, and then possibly merge them into one? A 2.0 release goal would be mega cool. Please keep this list updated. How about this for a strawman: would anyone on this list object to calling LukeJr's GammaMOO LambdaMOO 2.0, So long as the MOO code is backwards compatible with non GammaMOO cores. Minor enhancement request: * Remove the auto-aliases for : ; into a simple configuration file. (Eg to allow for ' - say ; : - emote | - eval) Rob ,'/:. Dr Robert Sanderson ([EMAIL PROTECTED]) ,'-/.http://www.o-r-g.org/~azaroth/ ,'--/::(@)::. Dept. of Computer Science, Room 805 ,'---/::.University of Liverpool /:. L5R Shop: http://www.cardsnotwords.com/ I L L U M I N A T I # This message is sent to you because you are subscribed to the mailing list [EMAIL PROTECTED]. To unsubscribe, E-mail to: [EMAIL PROTECTED] To switch to the DIGEST mode, E-mail to [EMAIL PROTECTED] To switch to the INDEX mode, E-mail to [EMAIL PROTECTED] Send administrative queries to [EMAIL PROTECTED]
[MOO-Cows] Re: forked moo servers
On Monday 06 December 2004 15:55, H. Peter Anvin wrote: Dr Robert Sanderson wrote: Minor enhancement request: * Remove the auto-aliases for : ; into a simple configuration file. (Eg to allow for ' - say ; : - emote | - eval) Probably should just be a server object control property. Or nothing? I bet this behaviour could be emulated completely with #0:do_command and force_input(). TTFN Andy # This message is sent to you because you are subscribed to the mailing list [EMAIL PROTECTED]. To unsubscribe, E-mail to: [EMAIL PROTECTED] To switch to the DIGEST mode, E-mail to [EMAIL PROTECTED] To switch to the INDEX mode, E-mail to [EMAIL PROTECTED] Send administrative queries to [EMAIL PROTECTED]
[MOO-Cows] Re: forked moo servers
As far as all this goes, I have a few suggestions. First, no offence to Luke-Jr, but I've ran into a lot of compilation glitches with GammaMoo and its code-quality isn't all that great. I'd suggest either starting from the current Lambda CVS and merging third-party patches for a 2.0 release or taking Foo (which has always compiled on everything I tried it on, at least :). Whether this is accomplished by taking control of the current SF project, or creating a second one is the first decision that needs to be made. The current SF project would have worked quite well, if patches in the patch tracker were ever actually looked at. That said, since I see a lot of the initial work to be simply gathering patches and improvements into the one central codebase the first couple of developers really just need to be decent coders who have enough time to actually look at the patches. Initially I'd suggest: * Two project admins for sanity (I elect hpa and dive) * Two or three developers to vet and commit patches and diffs. * Someone coming up with a moo-code core to regression-test the server * People making diffs Most of the development should initially be recommendations/diffs of code to merge. As long as quality-of-code is maintained and nobody runs out of time to merge or make patches, CVS should get up to scratch pretty quickly. And if the regression-core is ready, then all is good. Furthermore, I'd suggest that 2.0 have a 'plugin' system, for registering builtins by loading shared objects listed in a config file (Eg, LoadModule FUP). I'm hoping that everyone has posix dlopen() support or a wrapper by now? :) Cheers, -- James 'Ender' Brown http://www.quakesrc.org/ http://www.scummvm.org/ # This message is sent to you because you are subscribed to the mailing list [EMAIL PROTECTED]. To unsubscribe, E-mail to: [EMAIL PROTECTED] To switch to the DIGEST mode, E-mail to [EMAIL PROTECTED] To switch to the INDEX mode, E-mail to [EMAIL PROTECTED] Send administrative queries to [EMAIL PROTECTED]
