Gah, I'm sorry for not replying earlier. I still think this is an unnecessarily complex mechanism for basic functionality that is best provided outside of Wave. It's architecturally complex because it's a lot of code to go through the robot infrastructure when a simple servlet could directly access and modify the required data. It's also complex to the user because they need to interact with a robot, including knowing it's address, understanding how to talk with it, etc, etc. These usability things could be addressed with some effort, but it's a serious amount of work.
We're straining right now to get WIAB into a usable state. Being usable by a small organisation is a critical milestone to help WIAB gain both user and developer adoption. I just don't think that these are the right cirumstances to be experimenting with complex mechanisms like this when a simple solution exists. The general technique of running robots inside the WIAB server process is interesting. It needs some more consideration. Robots were always a means to move application logic out of the servers, to keep them simple. Hosting robots inside the server process adds complexity, adds ways it could fail, increases the likelihood of a robot bug taking down the whole server, etc. The code will need very careful review. On the other hand, in some cases it decreases system complexity by removing the need to run a separate robot server. I would like to hear what other people think about this idea. Alex P.S. At the wave summit we talked a little about our desire to push complexity out of the cores of the wave system, such as at the end of the wave model talk: http://www.youtube.com/watch?v=6ZqpeFydq4A Running robots inside the WIAB process is a good example of an architectural change that could have unexpected consequences. It's the kind of thing that deserves a design proposal and discussion before too much code is written. Lennard talked about this: http://www.youtube.com/watch?v=WpBrNUbB4sE On 25 November 2010 21:49, Vega <[email protected]> wrote: > I have a proof of concept implementation of the admin robot as > described above. > The first version of the patch is inside the issue : > http://code.google.com/p/wave-protocol/issues/detail?id=162 > > On Nov 20, 8:02 pm, Vega <[email protected]> wrote: > > Ok, I started to work on the admin robot for wiab. > > Here how I think it will work: > > Robot will be hosted on the wiab server, the robot > > ( [email protected]) will be registered automatically on server > > start up. > > The robot will be passed Injector into constructor so it will have > > access to wiab server objects (including accounts) > > The password reset module will be exposed as robot proxy i.e. services > > [email protected] > > If added to a wave it will allow to reset passwords via command line > > like syntax (using CLIhttp://commons.apache.org/cli/) > > The implementation will also add some abstraction layer to allow easy > > plugin of more admin modules as robot proxies. > > How does it sound? > > > > On Oct 29, 11:57 am, Vega <[email protected]> wrote: > > > > > > > > > > > > > > > > > Ohh. I intended to use Echoey code as example off course and extend > > > AbstractAgent. Is there an example of working robot? > > > > > On Oct 29, 9:20 am, Alex North <[email protected]> wrote: > > > > > > Depending what you mean by "agent-based", please avoid using the code > in > > > > box.server.agents. That code is earmarked for deletion; it was a rush > job > > > > and does things in an ugly way. Its presence significantly hampers > other > > > > development. We're only leaving it around to support the "echoey" > agent > > > > which is the only way to tell you've successfully federated with > acmewave. > > > > As soon as we've ported echoey to a robot we intend to delete the > code. > > > > > > You could build new code talking to the c/s protocol - with code > review I'm > > > > optimistic we can do it right this time. > > > > > > A. > > > > > > On 29 October 2010 17:58, Vega <[email protected]> wrote: > > > > > > > It seems to me that agent based password reset mechanism is pretty > > > > > simple. I ll try to implement it and see if it gets more complex > that > > > > > I thought. > > > > > > > On Oct 29, 2:04 am, Alex North <[email protected]> wrote: > > > > > > On 29 October 2010 10:44, Vega <[email protected]> wrote: > > > > > > > > > Hmm, I don't see a way how "password reset mechanism" can be > outside > > > > > > > of the > > > > > > > authenticated world.Adminshould be authenticated into something > (DB > > > > > > > at least). > > > > > > > > Sorry, I wasn't very clear. Yes, admins should be authenticated > when > > > > > > administering the user database. > > > > > > > > Any self-password-reset mechanism would need to be > unauthenticated (but > > > > > then > > > > > > rely on some other verification system, like sending an email to > a known > > > > > > address). > > > > > > > > > If you want the most simple wavy password reset mechanism - do > it with > > > > > > > agent. > > > > > > > -Invite agent into wave. > > > > > > > -Issue password reset command > > > > > > > -Agent has the access to users accounts, so it can check if the > user > > > > > > > is authorized for such action, if so - it resets the password. > Cannot > > > > > > > be simpler than that and easy to implement - and still wavy. > > > > > > > > I love your passion for implementing things the wavy way! > Experience has > > > > > > taught me that it's more complex than you make it out, though. > > > > > > > > > On Oct 29, 1:26 am, Alex North <[email protected]> wrote: > > > > > > > > I happen to agree with Vega that hosting profile information > in Wave > > > > > has > > > > > > > > many advantages. However I disagree just on one piece: the > login > > > > > > > > information. I do think the username and password need to > > > > > > > > be manageable outside of Wave itself. They provide kind of a > minimal > > > > > > > > bootstrapping environment you need. First you get a username > and > > > > > > > password, > > > > > > > > then you can log into Wave. > > > > > > > > > > Clearly the password reset mechanism needs to be outside of > the > > > > > > > > authenticated world. I think it's simplest to put basic > password > > > > > > > management > > > > > > > > (changing your password when you already know it) outside of > waves > > > > > too. > > > > > > > > Building data models in Wave is nice and flexible, but it's a > lot of > > > > > > > > overhead for something as basic as login credentials. > > > > > > > > > > In many cases, authentication will be delegated to some other > system, > > > > > > > LDAP > > > > > > > > for example. We're just trying to implement something basic > for > > > > > groups > > > > > > > that > > > > > > > > don't have such a system. > > > > > > > > > > On 29 October 2010 05:03, Vega <[email protected]> wrote: > > > > > > > > > > > The advantage is obvious - you have everything in one > place. > > > > > Another > > > > > > > > > advantage - the Wave environment - it means an option for > > > > > extension. > > > > > > > > > For example you can create a simple profile wave. Then you > (or some > > > > > > > > > 3rd party) can add extension that would import user info > from > > > > > facebook > > > > > > > > > etc... > > > > > > > > > > > On Oct 28, 1:03 pm, x00 <[email protected]> wrote: > > > > > > > > > > Even if you have a gadget, you still need an interface to > do the > > > > > > > > > > management. I don't see much advantage of embedding this > within a > > > > > > > > > > wavelet. > > > > > > > > > > > -- > > > > > > > > > You received this message because you are subscribed to the > Google > > > > > > > Groups > > > > > > > > > "Wave Protocol" group. > > > > > > > > > To post to this group, send email to > > > > > [email protected]. > > > > > > > > > To unsubscribe from this group, send email to > > > > > > > > > [email protected]<wave-protocol%[email protected]> > <wave-protocol%2bunsubscr...@goog legroups.com> > > > > > <wave-protocol%2bunsubscr...@goog legroups.com> > > > > > > > <wave-protocol%2bunsubscr...@goog legroups.com> > > > > > > > > > . > > > > > > > > > For more options, visit this group at > > > > > > > > >http://groups.google.com/group/wave-protocol?hl=en. > > > > > > > > > -- > > > > > > > You received this message because you are subscribed to the > Google > > > > > Groups > > > > > > > "Wave Protocol" group. > > > > > > > To post to this group, send email to > [email protected]. > > > > > > > To unsubscribe from this group, send email to > > > > > > > [email protected]<wave-protocol%[email protected]> > <wave-protocol%2bunsubscr...@goog legroups.com> > > > > > <wave-protocol%2bunsubscr...@goog legroups.com> > > > > > > > . > > > > > > > For more options, visit this group at > > > > > > >http://groups.google.com/group/wave-protocol?hl=en. > > > > > > > -- > > > > > You received this message because you are subscribed to the Google > Groups > > > > > "Wave Protocol" group. > > > > > To post to this group, send email to > [email protected]. > > > > > To unsubscribe from this group, send email to > > > > > [email protected]<wave-protocol%[email protected]> > <wave-protocol%2bunsubscr...@goog legroups.com> > > > > > . > > > > > For more options, visit this group at > > > > >http://groups.google.com/group/wave-protocol?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "Wave Protocol" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<wave-protocol%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/wave-protocol?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Wave Protocol" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/wave-protocol?hl=en.
