Smuxi

16:34:40 <meebey> its far from trivial though, as there is no solution yet
16:34:46 <meebey> it should be Mono.Addins based IMHI
16:34:48 <meebey> IMHO
16:34:55 <meebey> or MEF
16:35:20 <meebey> so before the refactoring, it would be prototyping

16:42:48 <meebey> from a invoking PoV, a new command API would not have any advantage
16:43:01 <meebey> but the issue is, there is no registry
16:43:09 <meebey> commands are delegated
16:43:18 <meebey> from frontend to engine to protocol manager
16:43:25 <meebey> so the frontend doesnt know which commands exists
16:43:31 <meebey> thus no command completion

16:58:23 <meebey> IMHO commands should be seen as "modules" and they are bound to 3 different domains: a) frontend b) engine c) protocol manager
16:58:43 <meebey> because each command by definition has no relation to others
16:58:49 <meebey> from a structure PoV
16:58:49 <ker> hmm... true
16:59:01 <meebey> they dont share state
16:59:07 <meebey> thus they should not be in the same class
16:59:30 <ker> but a subclass of the same base Command class
16:59:44 <meebey> sure, only to have a generic implementation

17:01:25 <meebey> you delegate the CommandModel instance to a command invoker, which is a factory that knows all commands

17:15:04 <meebey> IMHO in a perfect would, anything should be an aliase if its non-ambiguous 
17:15:10 <meebey> s/would/world/
17:15:28 <meebey> say, /j #foo should work as long as /join is the only command that starts with a j
17:15:36 <meebey> /usr/bin/ip does that
17:15:43 <meebey> ip addr
17:15:45 <ker> yea, that's neat
17:15:45 <meebey> ip add
17:15:46 <meebey> ip ad
17:15:47 <meebey> ip a
17:15:48 <meebey> all work