KomHTTP (Kommanche from Squeak) Discussion about modules and plugin architecture in Kom #squeak irc channel, 30.5.07 by Göran Krampe, Ken Causey and Janko Mivšek (sorry guys that my editor eat all your nicks bellow)
20:55] Miso: So what does Kom have that Swazoo hasn't?
20:55] modules (i think)
20:56] but how much those modules are in use by others?
20:56] Almost none AFAIK.
20:56] HV2 sure don't use it. Seaside doesn't either.
20:56] but there is kind of plugin idea behind them?
20:56] Yeah.
20:57] kencausey checks Swiki
20:57] which modules exist and what are they for?
20:57] back in 5
21:02] As far as I can tell Swiki doesn't using any modules.
21:03] Miso: At least some of them look to replicate some behaviour Apache provides, virtual-hosting, logging, other of the like
21:06] kencausey: so that modules are more or less orthogonal to basic Kom functionality?
21:06] Miso: Frankly, I probably don't know enough to really judge.
21:07] and how is a plugin effect achieved?
21:07] by simply loading a plugin package which override some hook methods?
21:09] I'm not sure I understand the question, but most instances seem to start by overriding the default implementation of processHttp
21:10] to put it into use you tell the HttpService to add it into the chain as it were
21:11] kencausey: into a chain? a http request / response chain?
21:11] It goes like this.
21:11] Miso: take what I say with a big dose of salt, I'm just looking at an old version and making some guesses
21:12] HttpService is the listener "shell". It has an instvar plug that it uses if it is set - otherwise is sends "self subclassResponsibility"
21:13] Seaside stuffs its own WAKom in as the "plug".
21:13] But if you want to use the module architecture you should use ModuleAssembly to construct a tree of modules.
21:14] The top module is called ModCore.
21:15] gokr: top?
21:15] As in class hierarchy?
21:15] The top of the "tree". Or root. :)
21:15] Not in this version, it's ComancheModule
21:15] and ModCore is a child with no children
21:15] Em... 3 secs
21:17] ModCore is a subclass of ComancheModule.
21:17] yes
21:18] kencausey: I'm not going to add support for the closure compiler's code in 0.12, that's definately out of scope.
21:18] wBryce: OK, maybe that's what I was thinking of
21:18] i am a c++/java developer im not famliy with the interface have i to open a new workspace and type the text there?
21:19] Miso: Well, what I said I'm largely pulling out of the air and has little basis in reality I'm afraid. But if you quote me on that early on, it's fine with me. ;)
21:19] Anyway, each "module" in the tree of modules is sent processHttpRequest: and if anyone returns true we return the response. So a module answering true terminates the traversal.
21:20] Eh, sorry, they are sent #processHttp
21:20] gokr: This functionality is implemented by ModuleAssembly?
21:20] No, the ModuleAssembly instance is only used to assemble such a tree.
21:20] In other words the 'chain' I posited before is really implementing by ModuleAssembly?
21:20] No.
21:20] gokr, that info even if it is not complete will help anyone later
21:20] oh, hmm
21:21] ModuleAssembly is just a "tool" to construct the tree.
21:21] Where is the tree held and queried?
21:21] The tree is held in instvar plug in the HttpService instance.
21:22] oh, so that's a collection
21:22] Eh, no - the instvar plug is not a collection.
21:22] See where I'm getting confused ;)
21:23] The plug instvar could be an instance of WAKom.
21:23] gokr: Mixing Seaside into this perhaps confusing the issue
21:23] Yes.
21:24] kencausey: I just meant that "plug" is any object that implements #processHttp.
21:24] gokr: Right, so if you want more than a single plugin?
21:24] If that object is an instance of ComancheModule (or its subclass ModCore) it will have potential children forming a tree.
21:25] ah yes, OK
21:26] So the different nodes in the tree can do logging etc - for example ModLog does this:
21:26] processHttp
21:26] HttpAdaptor current addPostProcessor: self.
21:26] ^self processSubModules
21:26] gokr: So it's like nodes in a tree? And each Module must itself implement the functionality of offering it's submodules an opportunity at the request?
21:26] As you see it does not return true and thus we will continue letting more modules deal with the request.
21:26] That seems like an odd implementation choice to me
21:27] yes, that is correct. 21:27] lots of repeated implementation of the same functionality
21:27] Modules that want the "tree behavior" subclass from ComancheModule.
21:28] Eh, no - not repeated - if you subclass from ComancheModule.
21:28] There are 11 subclasses of ComancheModule that calls processSubModules.
21:28] I see it repeated
21:29] What is repeated?
21:29] The logic to pass functionality on to lower modules in the tree
21:29] it's explicit in every implementation of processHttp
21:30] I am looking in a few of them and I am not sure what you mean.
21:30] somewhere each of them has the code 'self processModules'
21:30] Yes.
21:31] Sometimes they do stuff before, sometimes after, sometimes before and after etc.
21:31] So I can't see instinctively how that can be made much "cleaner".
21:31] OK, maybe this is a case where I'm falling into YAGNI
21:31] Well for example have explicit processPreHttp, processPostHttp for example
21:32] in addition to processHttp
21:32] each module can choose to implement any or all
21:32] But I won't say its obvious that this is any improvement, it's just more what I expected to see
21:32] Well, ModAlias also looks to see if the processSubModules returns true or false.
21:33] Anyway, this is how it works. :)
21:33] Yes, this may be the simplest way to provide all the options needed 21:34] So it is flexible as hell - and now that I look at it, it doesn't look that bad. But ModuleAssembly, ModCore etc - well, things can be confusing. 21:34] So, the question remains... Does anyone use it? ;)
21:35] And since for example Seaside just plugs a WAKom in there all the abilities are "moot".
21:35] Might be a question for the Seaside list
21:35] I suspect someone might override that though
21:36] I myself have overridden the default way Seaside sets things up
21:36] although perhaps my goal could have been met some other way 21:48] bmp> Chiming in, Seaside is ultimately implemented as a Kom module, unless I'm badly misremembering.
21:48] bmp> WAKom simply automates creating and installing it.
21:48] kencausey> yes, I think that's what gokr said in different words
21:48] kencausey> or not
21:48] bmp> I was rereading the transcript.
21:48] bmp> Not the backlog.
21:48] bmp> Probably should've read both before piping up. :) Sorry.
21:49] kencausey> No, you may be making a different point there
21:49] kencausey> WAKom is not itself the module?
21:49] kencausey starts up yet another image
21:49] gokr> It is.
21:49] gokr> AFAICT.
21:50] bmp> Reading Avi's code always leaves me walking away feeling like I tried to execute a Zen koan in my head. 21:50] kencausey> gokr: interestingly enough it does not subclass ComancheModule or any of its subclasses
21:50] gokr> It holds an "entryPoint" which is a WADispatcher.
21:50] gokr> Yeah, that is what I said.
21:50] bmp> But it's acting as if it were.
21:51] bmp> It's just implementing the methods it has to, without worrying about proper subclassing.
21:51] bmp> Another argument for traits. :)
21:51] gokr> I said "And since for example Seaside just plugs a WAKom in there all the abilities are "moot"."
21:51] kencausey> It certainly looks like a Module to me
21:51] bmp> I saw that; I just got confused, since you can in fact install Seaside in a master Kom process that includes normally served directories, ModAlias, etc.
21:52] kencausey> It just implements the entire functionality it needs directly rather than subclassing the standard base class
21:52] bmp> So I'm not 100% sure what you mean by it's moot.
21:52] gokr> Hmm, yes... ok.
21:52] gokr> I take that back.
21:52] kencausey> I think the point is that none of the Kom Module classes themselves are actually used
21:52] bmp> E.g., gokr, http://www.motionobj.com/seasidefaq/ServeStaticFilesWithComanche 21:53] gokr> Yeah, that is one way.
21:53] bmp> /seaside is taken as a seaside request, everything else is a normal file request (or any other module you plug in)
21:53] gokr> You should also be able to just use the WAKom instance as a node in a module tree (and not use a block plug).
21:54] bmp> And I hate how chat clients eat up /foo at the beginning. /seaside is not an IRC message. :-/
21:54] kencausey> prepend whitespace
21:54] bmp> That's cheating, kencausey :). Real men /msg #squeak /quit
21:54] kencausey> thbpt
21:55] bmp> /quit So long, suckas ;-)
21:55] bmp> /msg is fun
21:55] gokr> Anyway, perhaps the module idea is not that bad in itself. It is just not clearly described and slightly confusing to set up (the ModuleAssembly thing doesn't really help).
21:55] kencausey> Go work on some Java or C++ or whatever ;)
21:56] bmp> "not clearly described and slightly confusing" describes about 80% of all Squeak projects.
21:56] kencausey goes to work on some Lisp until Marcus gets here
21:56] bmp> Objective-C and C today. No C++.
21:56] gokr> But DynamicBindings surely must be overkill.
21:58] gokr> But Kom sure use it in a lot of places.
21:58] kencausey> yeah, it's pretty well intertwined at this point
|