What I mean is, in answer to the following: "This can't make it to the core cause it also introduces new builders".
... that effectively a distinction be made between between core services and application services - services vs utilities. Alikening it to an operating system - the difference between a kernel and OS utils/tools. Mmbase, the application should be allowed to expand no end, whilst the core services (kernel) should become as stable as possible. The distinction between "utilities" and what are currently known as "application" will then be determined by how generic they are and the interfaces they present to be used as a utility. If they are going to be hacked by developers building applications on top of them, then they are are in fact applications, but if they form an underlying layer of an application, then they are indeed utilities and effectively - from a final application developer's viewpoint, part of the mmbase "core" (whilst of corse, they are not part of the "kernel"). The debate therefore on whether something makes it to the core or not, will be determined by it's generic re-use in building applications - as determined by the developer using mmbase to build his application. Emile ----- Original Message ----- From: "André van Toly" <[EMAIL PROTECTED]> To: <developers@lists.mmbase.org> Sent: Wednesday, February 16, 2005 5:15 AM Subject: Re: [Developers] Improving the Developer Community (ideasandsuggestions) At 12:16 -0800 16-02-2005, Emile wrote: >André, is it not possible to devise install options, so that variations can >be applied by the target developer? In this instance, builders would be a That is of course possible, but would be a bit cumbersome when you try to adapt cloud context security (ccs) to use your own builders. In the case of ccs it would be easier to adapt the builders to reflect your own needs, like by introducing more fields in the builder mmbaseuser. Or do you mean that in the ccs application all references to builders and fields in builders need to be generic? And that you map these builders and fields with some configuration file? I, for example asked the designers of the chat application JIRC to make the user builder generic and the mapping to the right builder and the two fields JIRC uses from it, is described in a configuration file. But JIRC also uses the builders server and channel and i believe that these are really needed by the application (it's a chat so it needs a server and channels :-) and there is no need to make these generic or configurable, they are 'part' of the application. >suitable way of introducing options. Downloading extensions to mmbase >seperately is prohibitive in the mind of a new developer. It also means >that "mmbase" is the sum of all of it's parts, not just a core with added >options. It also means that testing mmbase would include all of the >applications installed as well. Not necessarily so. ---André -- André van Toly http://www.toly.nl mobile +31(0)627233562 ------------------------------------------------------------------>><<-- _______________________________________________ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers _______________________________________________ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
