I agree with your points, but it's important to understand the difference between "features" and "interfaces" (in the technical sense).
An interface is a common set of tools and basic code which has an API that plugins can implement. The ACL is an example of this. A feature is something like being able to make hidden private posts. This should be implemented using a plugin, but relies upon the core *interface* of the ACL. On Sep 24, 2008, at 9:34 AM, drzax wrote: > > In relative terms I'm new here, but I've really been around (somewhat > stealthily) for a while now. The reason I've been stealthy is > precisely because I didn't want to bring up or dispute things that > have already been decided on. That's why I know that > >> "default behavior" and "plugin" are NOT opposites. > > My opinion is that the 'core' should not *ever* be displaying draft > posts on the front end. Which is a change to how core currently works. > Implementing the 'preview mode' or whatever it becomes in a plugin is, > as you point out, best done in a plugin if we are to follow the Habari > philosophy. > >> Must we have this "plugin vs core" argument about every single >> feature? The answer is "plugin", and that answer was decided more >> than >> a year ago. > > That's simply not true. The answer isn't always 'plugin' (even if it > is most of the time). The plugin system is mature enough that pretty > much anything can be done in a plugin already. ACL? Vocabularies? > There are features being added in core all the time which could be > implemented in a plugin, but (the community/Cabal has decided) they > shouldn't be (decisions I usually agree with). This will continue to > be the case until...well...I don't know when. Actually, the core philosophy has always been to avoid feature bloat. However, we *do* encourage code improvements which make it easier for plugins to extend the core and create advanced functionality. By itself, in the present form, neither vocabularies or the ACL are useful: nothing in the core really exposes that functionality. However, the crux is that there are (or soon will be) APIs which allow plugins to build functionality centered around these interactions _without_ having to duplicate expansive schemas or code. --~--~---------~--~----~------------~-------~--~----~ 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/habari-dev -~----------~----~----~----~------~----~------~--~---
