Core/Not Core

Adonis

  • Skyrim Arch-mage and errand runner
  • Posts: 80
Core/Not Core
« 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).



MultiformeIngegno

  • Posts: 1,337
Re: Core/Not Core
« Reply #1, on October 13th, 2010, 07:34 AM »
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..

Nao

  • Dadman with a boy
  • Posts: 16,063
Re: Core/Not Core
« Reply #2, on October 13th, 2010, 07:46 AM »
Oh, my... Indeed, at least that would be a good way to settle the discussion about Aeva Media :P

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Core/Not Core
« Reply #3, on October 13th, 2010, 11:51 AM »
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.
When we unite against a common enemy that attacks our ethos, it nurtures group solidarity. Trolls are sensational, yes, but we keep everyone honest. | Game Memorial

Nao

  • Dadman with a boy
  • Posts: 16,063
Re: Core/Not Core
« Reply #4, on October 13th, 2010, 07:24 PM »
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.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Core/Not Core
« Reply #5, on October 13th, 2010, 08:12 PM »
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?)

Nao

  • Dadman with a boy
  • Posts: 16,063
Re: Core/Not Core
« Reply #6, on October 14th, 2010, 10:09 AM »
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...

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Core/Not Core
« Reply #7, on October 14th, 2010, 02:43 PM »
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.

Nao

  • Dadman with a boy
  • Posts: 16,063
Re: Core/Not Core
« Reply #8, on October 14th, 2010, 03:02 PM »
Quote from Arantor on October 14th, 2010, 02:43 PM
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>.
Quote
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...

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Core/Not Core
« Reply #9, on October 15th, 2010, 12:55 AM »
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)
Re: Core/Not Core
« Reply #10, on February 23rd, 2011, 02:51 PM »
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.

Dismal Shadow

  • Madman in a Box
  • Me: Who is Arantor? Cleverbot: It stands for time and relative dimensions in space.
  • Posts: 1,185
Re: Core/Not Core
« Reply #11, on February 23rd, 2011, 05:28 PM »
Agreed but I personal think calendar should go...
“I will stand on my ground as an atheist until your god shows up...If my irreligious bothers you much, and if you think everything I do is heresy to your god I don't care. Heresy is for those who believe, I don't. So, it isn't heresy at all!


   Jack in, Wedge,
   EXECUTE!

mikeymx5

  • Posts: 14
Re: Core/Not Core
« Reply #12, on February 23rd, 2011, 11:53 PM »
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".

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Core/Not Core
« Reply #13, on February 24th, 2011, 12:03 AM »
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.

spoogs

  • Posts: 417
Re: Core/Not Core
« Reply #14, on April 7th, 2011, 07:49 PM »
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.
Stick a fork in it SMF