Well... The trouble is that a plugin can't remove its own namespace in a clean way... In the other hand, if the plugin is buggy and doesn't remove its after script we will have plenty users who will yield about bugs in aMSN and that mean must things to do for us : it means that we will have to warn the plugin maintainer etc... The main trouble comes from that we can't approve or deny a plugin to be exectued... (that's a part of OpenSource : let's users do what they want :) ) So I think that's good for now... If you don't want to have the namespace : just restart aMSN... Phil
Tom Hennigan a écrit : > I don't think we could force it, but it should be considered "good > practice" for a plugin to remove it's own namespace.. > > On 5 Jan 2008, at 16:00, Karel Demeyer wrote: > >> can't we say that cleaning those after's is a task for the plugin >> maintainer to do in the de-init procedure ? If something bugs then, >> it's the plugin's fault, not aMSN ? For me it's weird that after >> unloading a plugin it's still polluting memory ... Also this would >> make it really easy to see if a specific plugin is loaded from other >> plugins (namespace exist ::namespace). >> >> No reason for a debate ? :) >> >> Karel. >> >> 2008/1/5, Philippe Valembois - Phil >> <[EMAIL PROTECTED]>: >> Because if they have after scripts pending that would cause huge bugs... >> And we can't clean after scripts :s >> Phil >> >> Karel Demeyer a écrit : >> > Why are we not deleting namespaces of plugins when they are unloaded ? >> > >> > >> > Karel. >> > >> > >> > >> > >> ------------------------------------------------------------------------ >> > >> > >> ------------------------------------------------------------------------- >> > This SF.net email is sponsored by: Microsoft >> > Defy all challenges. Microsoft(R) Visual Studio 2005. >> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> > >> > >> > >> ------------------------------------------------------------------------ >> > >> > _______________________________________________ >> > Amsn-devel mailing list >> > Amsn-devel@lists.sourceforge.net >> > https://lists.sourceforge.net/lists/listinfo/amsn-devel >> >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2005. >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> _______________________________________________ >> Amsn-devel mailing list >> Amsn-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/amsn-devel >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2005. >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/_______________________________________________ >> >> >> Amsn-devel mailing list >> Amsn-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/amsn-devel > > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > > ------------------------------------------------------------------------ > > _______________________________________________ > Amsn-devel mailing list > Amsn-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/amsn-devel ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Amsn-devel mailing list Amsn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amsn-devel
