[Babeldoc-devel] A conversation about modules

[McDonald, B. <Bru...@ba...>]

Hey all,

Here is a conversation that Dejan and I had about modules.  Basically the gist is that we want to make the modules lots more fine grained.  And that we want to distribute babeldoc as the core stuff and then 
users can select the features they need.

Also stuff in here about binary formats, documentation, etc.

regards,
Bruce.


dejan_krsmanovic: Bruce!1
triphopping_man: Dejan!
triphopping_man: I saw the check ins!
dejan_krsmanovic: Yeah. It is just a start1
triphopping_man: Why did you make the name of the module SOAP?
dejan_krsmanovic: I will create Jabber scanner1
dejan_krsmanovic: ?1
dejan_krsmanovic: Really?!1
triphopping_man: I saw the name soap all over the place
dejan_krsmanovic: I did use copy&paste from soap module1
dejan_krsmanovic: But I tought I have changed everywhere...1
dejan_krsmanovic: I will fix it1
dejan_krsmanovic: And I also think we should make separate releases for modules1
triphopping_man: Yeah - It will cause some trouble with existing code
triphopping_man: Sure - This is a good idea.
triphopping_man: We can break out whole sections of babeldoc into the modules
dejan_krsmanovic: I already mentioned that I think we should move most classes and libs out of main distribution1
dejan_krsmanovic: Yeah, I tought that too1
dejan_krsmanovic: For example we should make ftp module with ftp scanner and pipeline stage1
dejan_krsmanovic: mail module with SmtpWriter and MailboxScanner1
triphopping_man: ok - even break it up more
triphopping_man: yeah
triphopping_man: fine grain
dejan_krsmanovic: That way main distribution could be much smaller1
dejan_krsmanovic: ANd users could download whatever they need1
triphopping_man: Yes - just enough to build documentation
dejan_krsmanovic: We should decide which modules (plugins) will be in core distibution1
dejan_krsmanovic: All others should be downloaded separately1
triphopping_man: there are two issues here
triphopping_man: 1. The building of the readme directories needs to build coming from the modules
triphopping_man: we need to make sure that each of the documentation chapters can get merged into the overall documentation smoothly
triphopping_man: we can probably do that with just some javascript - to discover the chapters, etc, etc.
dejan_krsmanovic: Maybe we should leave documentation as is...1
triphopping_man: No - we cant
dejan_krsmanovic: Just mention that some stage or worker belongs to some module (plugin) and that it should be downloaded separately1
dejan_krsmanovic: Why?1
triphopping_man: If we go small modules, we need to be able to merge the documentation together.
dejan_krsmanovic: We can build everything when making release...1
triphopping_man: Its not that hard - it just needs to be done
triphopping_man: When we build the documentation - we need to find the chapters and make references in the userguide.xml - we can use javascript for that
triphopping_man: then each module gets its own "Appendix" chapter
dejan_krsmanovic: Hmm Yeah1
dejan_krsmanovic: Sounds good1
triphopping_man: The automatic finding of pipelinestages, scanners - all work as now
triphopping_man: nothing needs to be changed.
triphopping_man: so its just a small change to the finding of the module chapters - this will be a nice thing.
triphopping_man: You get a little part in both the userguide and devguide for each of the modules
dejan_krsmanovic: Maybe we could include additional, module specific documents 1
triphopping_man: Now here is part two of the probvlem:
dejan_krsmanovic: Like examples, etc...1
dejan_krsmanovic: Not just generated documents from stage/scanner1
triphopping_man: Yes - they can go in the module specific chapter
triphopping_man: Exactly
triphopping_man: That solves that problem
dejan_krsmanovic: So you could write some examples, some additional explanations...1
triphopping_man: (yes - remember the discussions while back about this)
dejan_krsmanovic: part two...1
triphopping_man: ok
dejan_krsmanovic: You started something about part two of the problem..1
triphopping_man: We need to think how we build and distribute both source and binary versions of the modules files.
triphopping_man: we need to come up with a format (name, directory structure) for the source and binary module distributions.
triphopping_man: Not everyone will want to download and build the module source code.
triphopping_man: The binary module must be able to unpack and integrate with the larger babeldoc build.
triphopping_man: integrate with the core babeldoc build.
triphopping_man: maybe we can make a pipeline that does this.
dejan_krsmanovic: Wouldn't it just be possible to download babeldoc_something.har and put in lib?1
triphopping_man: what about other files that are needed?
triphopping_man: other jar files
triphopping_man: other documentation files?
dejan_krsmanovic: Hmmm. When I install Eclipse plugin I just extract zip file into plugins folder.. Plugin already contains jar files1
dejan_krsmanovic: Maybe we should use same approach1
triphopping_man: fine - then we just unjar the module-binary "over" the babeldoc distribution
dejan_krsmanovic: Create a plugin (or modules) folder where modules should be extracted1
dejan_krsmanovic: Yeah1
dejan_krsmanovic: We can adopt some naming convention1
dejan_krsmanovic: Like com.babeldoc.jabber....1
dejan_krsmanovic: Or something like that...1
triphopping_man: Well, if we create a modules folder - then we need to improve the classloader to load from the lib directory for each module
triphopping_man: what else...
triphopping_man: that should be it.
triphopping_man: each module is like a mini babeldoc in structure...
dejan_krsmanovic: Yeah...1
dejan_krsmanovic: And files should be have unique names...1
dejan_krsmanovic: We will think about it later.1
dejan_krsmanovic: I am in office 1
dejan_krsmanovic: And I should be home now 1
dejan_krsmanovic: Talk tomorrow!1
triphopping_man: Ok - lets get 1.2 out and we can do this cool stuff
dejan_krsmanovic: Yeah..