On Mar 15, 10:51 pm, The Editor <[email protected]> wrote:
> Being as 3.4.6 managed to go out without immediate reports of bugs and
> problems I have my fingers crossed we may have finally gotten it
> right. Well close enough at least to be able to focus real attention
> on the transition to 4.xx.
>
> Here are my goals for the transition:
>
> 1) My main goal will be to rewrite the forms processing engine so that
> all commands have to be executed as session variables (perhaps even
> [command ... ...] rather than "session"), and make it possible for
> them to take multiple parameters just like functions. This will allow
> us to simplify many things, enhance security, and make things a lot
> easier to use.
session -> command
Excellent.
> Though a great improvement all the way around, and simple to do, it
> will likely require us to examine virtually all of our existing custom
> forms, and rewrite many of them. This is the main reason for the
> switch to 4.xx. Unfortunately, this will be a pretty big disruption...
>
> 2) While not originally on my radar, Markus suggested some renaming of
> our installation directories in a recent thread that really resonated
> with me. It won't be difficult to code, or to implement, but the 4.xx
> switch is the ideal time to make such a change. Getting the docs
> caught up might be a bit more challenging! We may even make a few
> changes to our "brand" and the like to focus more on the idea of
> "engineering the web" or something.
I'll put my tractor on eBay then.
As you mentioned the docs. I have two ideas.
1) I propose to build a library: a collection of code.
library
library.forms
library.searches
...
Everybody could post their excellent inventions in a structured manner
with a sentence explaining what it does. A place for inspiration, to
see what is possible and for potential new users to see what BoltWire
actually is all about. Think of it as structured and categorized
snippets in a uniform presentation.
2) I propose to create a built-in API. The current help system is for
programmers. Users need something else:
search:
* group: Limits search results to a group.
* count: ...
* link: ...
You know, the kind of tabular information that is split all over
BoltWire.com. We need it in one place. An alphabetical list of
parameters for each function. And maybe a list of config options and
other useful things. Like an API.
> 3) My other goal is to go through the entire source code with a fine
> tooth comb, and strip out every feature, config option, unused
> parameter, function, command, conditional, etc., that we possibly can
> without weakening our core engine. I've grown concerned that BoltWire
> is getting bigger, slower, and clunkier, rather than leaner and
> faster. A good while back we broke my self-imposed 100k barrier and I
> aim to reclaim it.
>
> To do this, I will be soliciting feedback from you concerning which
> parameters and config options you actually use. And which features we
> could relegate to plugin status without affecting too many sites. My
> guess is we could strip out half the optional settings and no one
> would notice. Other than downloads being smaller and things running
> peppier. But we'll see...
Config options I changed:
defaultPage:
language:
mailAddress:
mailMode:
sitemail:
skin:
uploadCase:
uploadSize:
uploadTypes:
Config options I would show by default:
defaultPage:
language:
stampsExpire:
sitemail:
skin:
uploadCase:
uploadSize:
uploadTypes:
Config options to not show by default:
All others. I would place them in a prominent way on a docs page that
one can go through to see what settings are available.
For unused functions and the like I propose you make a list of
everything you are willing to drop, send it to the list or make a poll
and see how many of us will complain. I don't think many of us can
tell you to drop function x, if we don't use it in the first place.
Or strip out everything you want and make some funny Russian roulette
release.
> 4) While the core will hopefully be slimming down, I also would like
> to offer a BoltWire Pro release which will consist of the exact same
> lite core, but with an extra script called community.php, and dozens
> of additional system pages. This extra script will include 5 or 10 of
> my favorite plugins fully set up and functional--with real help pages!
> Things like newsletter, rss, store, tree, and commentbox, and pages
> for things like email verification, password reminders, profile pages,
> blogs, forums, and tags. The idea is that the BoltWire Pro will be a
> ready to go full-featured CMS application. While BoltWire Lite, a
> bare-bones but fully functional engine for building your own CMS or
> any other kind of application you want.
>
> My plan is to support both, the Lite and Pro versions, as two separate
> downloads. Possibly with a small fee for the extra Pro features,
> perhaps on a suggested donation basis. Both Lite and Pro will run on
> the exact same basic engine, and the Lite version will not be disabled
> or weakened in any way, and it will remain, as always, free.
Now, I'm relieved. I was a bit worried when I heard Lite and Pro. Do
yourself a favor and think again about the naming. Neither one is Lite
and neither one is Pro. Isn't it more Pro if you program your site
from scratch? Also Lite users will experience mental trauma and feel
like second-class users. There is a high chance I would not even be
writing this if I spotted the evil words Lite and Pro the first time I
visited BoltWire.com. I always expect Lite versions to be "forgotten"
sooner or later or to be designed to miss just the one feature you
can't live without.
What about "BoltWire Scratch"/"BoltWire Core" and "BoltWire
Box"/"BoltWire CMS". Just keep it neutral.
(Or "BoltWire for Engineers" and "BoltWire for Farmers"... :))
Users could by the way contribute their own BoltWire editions for
custom scenarios. Sounds a lot like Linux.
> Here's a few thoughts on the process:
>
> I'm not sure the exact process at this point. Once we go to stable
> 3.5, I will probably start 1) going through the core and trimming
> things down and simplifying the code for a few releases. To get it as
> close to ready for 4.xx as possible. Then 2) change the directory
> structure and form commands in one big blow and call that 4.00. At
> this point we will freeze the feature set. There will be 3) a few
> releases to polish off any bugs, (though the code changes won't be
> significant at this point and bugs should be few) and start patching
> up skins and plugins, etc. Finally, once I have the new community
> script and pages ready to go, I will 4) release BoltWire Pro. And
> spend a few releases trying to get it squeaky clean.
>
> At that point, my goal will be to stick with the Lite/Pro feature set
> for a good long while--only releasing minor maintenance patches. In
> fact, I'd like to get on aregular release schedule, something like
> "significant" upgrades no more often than once every six months or a
> year. Rather than once every week or two... :)
>
> Feedback on the goals/process for 4.xx are welcome. As well as any
> last calls for features you would like to see in BoltWire...
Maybe mentioned before. Please improve the search:
* Wildcard asterisk ("bolt*")
* No results found? Please tell me (maybe optionally).
* Limiting results? Please tell me and if there is a way to see more.
Maybe search could produce a link to display the next x results.
Regards,
Markus
> Cheers,
> Dan
--
You received this message because you are subscribed to the Google Groups
"BoltWire" group.
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/boltwire?hl=en.
