Yes In fact usman got interested by the package because we should deploy application to clients with restriction. Now we should rethink it if this is to be integrated in the image. Now one of the problem is that benjmain cannot manage it completely with a configuration because some code can only be applied using CS and this is this point that we should look at.
Stef > Firstly we need to aswer on question how deep this mechanism should be > integrated with the kernel. If kernel should be able to work without > UsersManger, if Monticello and Metacello should be able to work > without UsersManager, if we should provide some basic minimal > UsersManager implementation etc. > > currently the have problems with this methods: > Author>>fullNamePerSe > Author>>fullName: > MCHttpRepository>>password > MCHttpRepository>>user > > -- Pavel > > On Sun, Dec 23, 2012 at 2:13 PM, Stéphane Ducasse > <[email protected]> wrote: >> Yes we should unload it. >> Now I would like to know what are the hooks that we need in the kernel to >> support its smooth loading. >> >> Stef >> >> On Dec 23, 2012, at 1:48 PM, Pavel Krivanek wrote: >> >>> There is a lot of reasons why I think that the whole concept of >>> UsersManager is poor: >>> - direct dependency on cryptography packages >>> - there is only one current user. What about if more users is >>> connected to one image? >>> - users avatar as an ImageMorph! >>> - permissions do not reflect modular architecture. Why to have >>> permissions like canBrowse canDebug canEditCode canEvaluateCode >>> canInspect canShowMorphHalo for image that has now browser, no >>> debugger, no editor, no inspector, no compiler, no Morphic? >>> - in Smalltalk this permissions bring no real security >>> - UsersManager is not an abstract class >>> - everything is in one package >>> >>> Thanks to this addition in current state the Pharo Kernel is not able >>> to load Monticello packages and in most cases even start. We really >>> need to reject it for Pharo 2.0. >>> >>> Cheers, >>> -- Pavel >>> >>> On Thu, Dec 20, 2012 at 5:23 PM, Stéphane Ducasse >>> <[email protected]> wrote: >>>> I think that we should remove the keyChain and it would be good that the >>>> system offers the right hooks so that keychain can be nicely added. >>>> Apparently ben add to provide a cs because some changes could not be >>>> applied via a slice. >>>> I planned to have a look but so far I did not find the time. >>>> >>>> >>>> >>>> On Dec 20, 2012, at 2:07 PM, Pavel Krivanek wrote: >>>> >>>>> It broke following Pharo Kernel jobs because the image crashes when a >>>>> directory is changed. So how to fix that. We have several options: >>>>> - make simple ugly fix that will check presence of this class, it will >>>>> generate unimplemented calls >>>>> - remove it and add it back fixed in 3.0 >>>>> - rewrite the Author change mechanism to Announcements (in 3.0?) >>>>> What do you propose? >>>>> >>>>> -- Pavel >>>>> >>>>> On Sat, Dec 15, 2012 at 3:01 PM, Esteban Lorenzano <[email protected]> >>>>> wrote: >>>>>> it was in the list of things to integrate :) >>>>>> but we should check to clean the dependence, because is not good. >>>>>> >>>>>> Esteban >>>>>> >>>>>> On Dec 15, 2012, at 2:16 PM, Pavel Krivanek <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> what is the reason for integration of KeyChain/UsersManager to the >>>>>>> image? It created the next kernel dependency. Should it replace Author? >>>>>>> Should it be in the Pharo Kernel? And why there was no mention about it >>>>>>> in this mailing list before? ;-) >>>>>>> >>>>>>> Cheers, >>>>>>> -- Pavel >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> >> >
