Wedge
Public area => The Pub => Features => Topic started by: Adonis on October 13th, 2010, 04:58 AM
-
Frankly, I don't know.
I don't set up forums very much, nor do I poke and see what is/isn't installed on my favourite haunts.
But, I notice that hardly anywhere has a 'One Download Fits All'. Most places have a 'Lite' and a 'Extended' version. Others go a bit farther and have a few different packs aimed at certain types of clients (see Adobe:Suites). Still others do the 'Download the Checkboxed Items' (see Windows Live Essentials).
I'd probably think the Lite/Extended would be the way to go. Organize the mods by general function (Social, Moderation, Graphical) - with the option to d/l them in groups (the ones done internally anyway).
-
Uhm.. I like checkboxes! I'm wondering if there would be support issues with them.. maybe for us would be difficult to understand what "version" with what plugins a user have..
-
Oh, my... Indeed, at least that would be a good way to settle the discussion about Aeva Media :P
-
Agreed on the AeMe front. Would also be neat for some of the other stuff we've talked about being core vs not core, like the calendar.
With a sufficiently modular setup it should be possible to do.
-
Yep...
I'll start thinking about how to split the things off.
Only problem is the database. I'm not sure we can create the AeMe tables all the time... But OTOH, they're relatively few, compared with the number of tables we'll be adding in the future.
-
It's still the case that we have the package manager, though again that will likely be upgraded since frankly I'd rather create a proper system under <database> to define tables so that modders never actually have to touch code. (I mean, seriously, I know the team regards packman as unfinished, but did it never occur to them in what ways it could be made nicer?)
-
Yeah, database stuff, good idea because it would also allow the packman to ask the user whether they want to delete the custom database stuff whenever they're uninstalling the DB... Then they won't have to ask support whether they can safely uninstall to upgrade, etc.
Something like this:
<database>
<table name="new_table">
<field name="id" type="int" size="4" default="" />
</table>
<table name="members">
<field name="you_stink" type="string" default="But life goes on..." position="after" target="id_member" onupgrade="empty_this_field" />
</table>
</database>
Yeah... I can see it working very well.
I'm trying to think of ways to make the packman work as well without getting mod conflict issues... Something like, putting existing code inside comments (/* wedge_mod_THIS_MOD_ID_begin: existing code here with comments turned to *COMMENT* instead of /**/; */ new_code here; /*wedge_mod_THIS_MOD_ID_end */), things that would even enable the mod to be upgraded automatically without uninstalling or using an upgrade script... Things like that... But it's not working out now...
-
Something like that, yeah.
Basically you won't be able to make packman ever work that well in its present form, simply because of the way it has to work. If you're search/replacing, invariably two things are going to collide - it's simply a matter of time.
That approach is interesting but flawed - I don't think /* */ syntax works properly inside SQL for example. It needs something totally different to be applied to it.
-
Something like that, yeah.
Me likey, but I'm not sure how long it'd take to implement.
Oh god, I wish I would have thought of that earlier: <IDEA>. A tag to help me find cool ideas that are buried inside a topic. Just so they're easier to find later...
So, without further ado: <IDEA>.Basically you won't be able to make packman ever work that well in its present form, simply because of the way it has to work. If you're search/replacing, invariably two things are going to collide - it's simply a matter of time.
That approach is interesting but flawed - I don't think /* */ syntax works properly inside SQL for example. It needs something totally different to be applied to it.
I dunno about that, I just know it's an implementation that doesn't solve all of my issues... I was thinking about mod upgrades first... But then I figured the problem with different mod collisions would still be there.
One solution would be to simply uninstall all mods chronologically (latest to first) until the upgraded mod is found. Then uninstall that mod, and reinstall all other mods in order. Of course it could only work if none of these mods were then hacked into by admins...
-
The hardest part of implementing it is unpicking the craziness in the package manager. Everything else is relatively straightforward (it's essentially scraping the XML for enough to be able to call $smcFunc functions)
-
It's funny, a lot of the things we've talked about that we said we were going to pull out of core, I find myself justifying keeping in core: calendar, AeMe and so on.
In fact, I don't think I've found a single thing that I feel comfortable pulling *out* of core these days... at least nothing much more than minor line items in the ACP.
-
Agreed but I personal think calendar should go...
-
I like how SMF has in the ADMIN Panel where you can turn CORE features on and off... Basically its one package but you select what you need.
Why the big rush to pull everything from the core?
Remember you are developing for the masses and not just a individual. Many people use the forum package for many different reasons and if people just want a Lite version of a forum they can get that its called PHPBB. :) JK
But my point is if a feature is not being used you should ask why and not if it is needed. Once you understand the first question "Why" you can answer the second question "Is it Needed".
-
Exactly. It took me a while to come round to that, but that's what happened. I started asking why no-one used it, and it's because it doesn't serve much purpose right now.
-
I wouldn't say no one uses it, I do albeit limited but I make the best use I can of it. Not sure where I stand on whether it should be included in core or not, but it definitely needs a more powerful event manager behind it (or should I say I need that)
The checkboxes option sounds good for a fresh install, I tend to be a minimalist not wanting things around that I dont use.
-
Something that could also be cool is that all wedges come with a lite package and in the package manager an admin can download, and install ( after the forum is installed ), the most updated core packages strait from a special core mod repository on dl.wedge.org. You could then integrate the pakage manager with all the available core/optional mods in that central location. A very good example is windows update and apt-get. Smf has something similar, but it is far from the same. This way you dont have to decide core or not, the site admin installs what they want, from call to aeva, to anything else. And your modders could just upfate their mod and everyone would automatically recieve notification of a new version similar to the smf version checker currently in place.
-
Picking up on what texas has said, a better example (to my mind) is the Module Admin in FreePBX.
Hard to find direct screenshots, and I'm not running PIAF at home any more to take some of my own, but you're presented with a list of modules that your PBX can run (if you so choose), updated modules are clearly indicated (with bulk installation of all updated modules being a two-click operation), and pre-requisites are dealt with by auto de-selecting modules that rely on modules that aren't currently installed during module installation.
If you have a VMWare/VirtualBox VM mechanism available to you, it's worth a look.
Update: No screenshots, but plenty of YouTube videos - Upgrading and adding modules to FreePBX on PIKA WARP appliance for Asterisk(http://www.youtube.com/watch?v=NdGOMBcsp5Q#) and skip to 01:00.
-
I don't really see how to offer a proper 'version update' system without locking modders into using our plugin website. I don't know, maybe just storing a URL linking to a page that returns the current version number & update URL, or something like that... It's something that we'll have to think about when we get ready to build said mod site, really. Not before.
-
Picking up on what texas has said, a better example (to my mind) is the Module Admin in FreePBX.
This is basically what Debian/Ubuntu and to a much lesser degree, Red Hat/CentOS and co do; you have a central repository of packages, you can add in new package repositories, but intra-package dependencies are a PITA, and just for fun, if you step outside the package repos, you get into a world of hell of maintenance, far more so than admins currently have on SMF.
I dislike the idea of forcing a centralised system unless 1) the centralised system is designed to be the *only* place to get packages (a la Apple's App Store) and 2) it allows paid packages and provides appropriate measures for modders in that regard.
And there's a world of hurt in there if not managed properly regarding "openness".
-
We never said it'd go ;)
And indeed we can only enhance it in the future.
-
YAY!
The only board that I have that is really active is very calendar based and an attendee list would be awesome.
-
It's just that there's so much to do/add... :^^;:
I've pretty much given up on it for Wedge 1.0 (otherwise we're sure to release in 2012...), but there are things I'd like to implement in 1.1 at least: the thought system, personalized profiles, etc...
-
We're miserable, that's what we get.
That's the problem with being smart. You think too fast and you're unhappy.
-
Couldn't find default topic for core to post this, so here goes...
I came across to this tip/trick and I like this idea of having a float around the poster info, that way it does waste space.
http://www.simplemachines.org/community/index.php?topic=445250.msg3127879#msg3127879
If you look at Arantor's post(http://wedge.org/up/6820/blog-post/) you will see there's wasted space below the poster info.
-
Waste Really? More like breathing space to me.
Floating userbox is okay in theory but will fall apart as soon as a post will start using complex layout like image alignment or tables or code boxes. It would distract attention I'd say.
-
I agree with some of the above comments, you can't keep adding more and more features as you end up with a bloated platform.
Ideally you want as many of the core functions eg not the forum itself to be optional.
Eg calendar, blog, etc
-
Nah, I beg to differ... If the new features don't hurt performance at all, and if you don't even notice them (only if you're *looking* for them), it's not bloat ;)
SMG went from 400kb (early versions) to 750kb (AeMe), nobody ever complained about bloat ;)
-
That's something I've noticed during overhaul of the admin panel, that other than post moderation and the calendar, none of the "core features" really seem to me to make much difference in terms of performance (profile fields, for example generates no extra overhead at all whether it's enabled or not, it's only when you start creating new fields that it becomes important)
I consider Word bloated because it has an awful lot that most people won't use, IMO; the usual claim is everyone uses only 10% and that everyone uses a different 10% but my experience is that the 10% claims aren't of all the features - most people use a very very limited subset so that you could prune 80% of the features and probably 95% won't notice.
I don't think we're looking like we're going to be bloated in the core, though, because I think what we're doing suits a suitably large percentage of sites.
-
I consider Word bloated because it has an awful lot that most people won't use, IMO; the usual claim is everyone uses only 10% and that everyone uses a different 10% but my experience is that the 10% claims aren't of all the features - most people use a very very limited subset so that you could prune 80% of the features and probably 95% won't notice.
But I'm sure 20% of the pruned features would be missed by 15% of the user base on at least 5% of all forums.
What were you saying already? :lol:I don't think we're looking like we're going to be bloated in the core, though, because I think what we're doing suits a suitably large percentage of sites.
It suits ours to begin with, and we have both simple and complex needs :P
-
Fundamentally though the internet has moved on.
Just like the old coding for old browsers we hate so much in SMF, the same goes for some features.
Although some users will expect the same 'old' same 'old' most of the new people to board software expect something more akin to twitter, facebook, google+ etc.
-
That's probably true...
Although Facebook & co. mostly borrowed ideas from earlier implementations, too. Social networks have been around since 2000 or so. Forums had time to adjust, at least to match the earlier implementations...
-
Yup. And we have removed some features, though generally they've been minor ones.