tradenet

  • Life is a never ending upgrade...
  • Posts: 5

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Unknown's thoughts on Wedge
« Reply #31, on June 28th, 2011, 10:55 PM »
OK, so I've had time to settle, digest and figure out what I want from this, and why, including what I want as a regular admin/user as well as a mod developer.


I want mods that do not have to rely on version checking. I want to avoid all the explicit checks that SMF has to make.

I want it so mods will *most likely* work between different versions. There are so many threads and questions about mods that only state a given version or versions, and whether they'll work on a later version. Even with SMF's policy of pushing out patches, people still ask whether a given mod will work or not because most people don't know or want to have to get involved.

Going primarily hook based means this sort of thing can be minimised because you have a setup whereby you can tell what mods are "most likely compatible" automatically, by whether a given mod requires what hooks and whether those hooks are present or not.

Having direct edits threatens this on a variety of levels, because you can't really determine *reliably* if it'll work. All you can do is validate whether the same code still exists or not which from bitter experience, isn't that reliable.

Retaining file edits does encourage version dependent coding. It also doesn't discourage abandonment - mod authors, generally, want to do as little as possible to maintain their mods. Making them do any more work will discourage them from writing mods. There are a great many mods on sm.org that are perfectly functional on current versions, but due to version checking brittleness, aren't used (and breed questions as above)

That said, there is a place for file edits. If they were used, the version checking would have to be used - that alone should be fair motivation for them to avoid doing file edits where possible.

As a user, I just want them to work. I don't want to have to fudge version checks with version-emulate, no matter how convenient it is to override it. I want it to work and not have to inconvenience the mod author any more than necessary. (And if I can encourage them to do it a better way by making it less work for them, awesome.)

I also know from bitter experience that mods editing files can be a pain. Incidentally, the problem is confined to specific classes rather than general. Most of my mods never had many problems because I was careful to avoid making more edits than necessary, and I would go to ridiculous lengths to avoid template edits except in the admin templates (e.g. SD 2.0 edits the IP tracking area of the profile, the manage attachments template and the packages template, and that's it, despite interacting with the board index and the main index templates)

What tends to happen is that mods which hit up the same place tend to collide, for the obvious reason, not only code collision but mods conflict with each other subtly; there's a mod, for example, that converts the board index layout to have a separate posts and topics column rather than a unified column - but any mod that then tweaks the layout (or has a different layout entirely) is going to conflict. (As it happens, I did most of this for SD in one of the output buffers, so it wasn't an issue)

Thing is, that's not going to go away, even with hooks. But it will be a lot easier if done with hooks and made easier to manipulate.

The consequence is that manual intervention is deemed the norm, even expected. It's hassle for the mod author and hassle for the user, and separating it structurally will make it easier. But it won't fix everything, so hooks will possibly make it more complex, but could often solve most of the problems if done properly.

So, let's assume for the present that we do preserve file edits, and that we make it discouraged (big warnings, etc.), we still have to contend with file permissions. I have seen far too many cases where file permissions are a headache, even with WordPress upgrade installs, and I dislike the problems it causes:
1. It makes people have higher permissions than they actually need.
2. It is a major cause of people hitting mod_security errors where they throw 777 permissions at everything.
3. It is very likely also a contributor towards installations being compromised and hacked. That was partly why the krisbarteo hack in 2009 was so successful, so many setups had permissions they shouldn't, meaning a dangerous attachment was able to trigger and infect any SMF files it could find. In some cases it was even observed to be the entrance for an entire server to be compromised.

While it can be 'made more reliable', I have lost count of the number of support issues that emerge every single day with SMF because of file permissions. Admins don't want to be bothered by it, they just want to install things without having to run a gauntlet. They just want to, at worst, set it up once and then it's done.

Add to that, people are naive. I have also lost count of the number of people who deleted a package and expected it to be removed. More than that, if a single file edit is going to fail, most people will assume there is a problem with the mod, plus most mod authors end up being expected to field problems with installation even if it's an SMF issue.

I could go on, I can find you more and more reasons to discourage file edits, and I hope this is enough to discourage mod authors where possible.

I mentioned before about specific classes of mod having issues. It's funny how the classes of mod that have trouble are that already mentioned, and the big mods. I remember in the early days having to spend time juggling SD's code to avoid tripping up on the portals, and even then people still have to uninstall things in the right order. This is something that, as far as I'm concerned, should just not be necessary for typical users to have to contend with.

It also implies a mod registry in the database being maintained, and having seen how many times there have been problems with this, it's even more a cause for concern (any mod that's manually installed will not appear in any of the registries unless the install was still performed and failed edits done afterwards)

What I propose, then, is that hooks are strongly encouraged (and, let's be honest, I expect to write most of the 'most wanted' mods myself) but that we do keep file edits. But, not only do we have warnings, we make the user have to manually enable it first, to understand all the consequences. Plus, we can manage it through the repository to advise the user that manual edits will be required.

In other words: I'm prepared to accept mods doing file edits if we make it a not unreasonable hurdle, and to use hooks for most things, because while file edits are convenient for the modder, they're not beneficial for the user, and it actively makes it harder to work on in the long run.

I still think it will cause friction because modders are still going to do that because they're used to it. I also think it will breed all the bad habits that SMF has - and I would rather breed a better experience for users than the developer experience, but I can see the benefits to keeping file edits.

I would retain the warnings etc even for Wedge patches because I don't see it being any better. Our intention for updates is for proper upgrade packages like SMF's rather than patches, which is better when using hooks because you don't have to wait for modders to update and in most cases you can update and just carry on using mods as you were before.

Mods that require direct edits will naturally require version bindings, but everything else can be function detection based. I'll be sure to write mods that don't require file edits, and since that will settle a decent proportion of the 'most wanted', I suspect it'll encourage good habits.

But I think any more than that will be a case of putting out the tools and hoping developers make use of them - we can encourage, we can demonstrate but we can't make them do it... and if we did *make* them, we'd be no better than the environment we left behind, and to me it would compromise the very freedom that Wedge was founded on.
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,079
Re: Unknown's thoughts on Wedge
« Reply #32, on June 28th, 2011, 11:18 PM »
The best way to encourage modders to use hooks is to remind them that Wedge will never get upgrade patches -- only full releases (or possibly small releases with only the updated files.)

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Unknown's thoughts on Wedge
« Reply #33, on June 28th, 2011, 11:28 PM »
That's the thing: it could be a good kick up the arse to do it right the first time, or a middle-finger because so many modders wouldn't sit and maintain mods for different SMF RCs, which is virtually the same thing on a technical level, if not a semantic one.

Plenty of examples and docs should help though.

Nao

  • Dadman with a boy
  • Posts: 16,079
Re: Unknown's thoughts on Wedge
« Reply #34, on June 28th, 2011, 11:44 PM »
Sure.

(Go answer the Font topic, you naughty!)
Posted: June 28th, 2011, 11:38 PM

Oh well I'll just go to bed...

groundup

  • Posts: 25
Re: Unknown's thoughts on Wedge
« Reply #35, on June 29th, 2011, 03:55 AM »
Arantor, at some point you are going to need to rely on versions or you will never move forward. You can loosely couple but if you overdo that, you wind up with Limp instead of Wedge ;)

Eros

  • I has a thought. Be afraid.
  • Posts: 56
Re: Unknown's thoughts on Wedge
« Reply #36, on June 29th, 2011, 04:48 AM »
Well, Arantor, for what it is worth...I agree with that choice, even if I think motivating developers out of bad behavior can't be done with file edits vs. hooks. ;)
18+ Roleplay Forum <- hopefully running Wedge when it is ready.

Yaoi RP Forum <- hopefully running Wedge when it is ready.

Nao

  • Dadman with a boy
  • Posts: 16,079
Re: Unknown's thoughts on Wedge
« Reply #37, on June 29th, 2011, 07:36 AM »
I'd like to reiterate my original idea.

Disable file edits at least until Wedge is out of beta.
If people rely on file edits when they can't find a hook, we'll never get people to get us to add hooks.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Unknown's thoughts on Wedge
« Reply #38, on June 29th, 2011, 10:12 AM »
Quote from groundup on June 29th, 2011, 03:55 AM
Arantor, at some point you are going to need to rely on versions or you will never move forward. You can loosely couple but if you overdo that, you wind up with Limp instead of Wedge ;)
Other than for file edits, why do I have to rely on versions?
Re: Unknown's thoughts on Wedge
« Reply #39, on June 29th, 2011, 10:49 AM »
See, here's what people don't realise about me.

Before I came to PHP, I did ASP.Classic, and before that, Visual Basic itself. Except I was doing stuff using the Windows API itself because VB's own set.

And the stuff I wrote 10 years ago... with one exception, it all still works on Windows 7. That particular exception is because of an API that was deprecated back in 2000, and naturally doesn't exist now. If you can do this on an operating system, why can't we apply the same basic techniques to programming in a higher level environment?

As far as what I want Wedge to be, I want to take SMF and fix what I see as the problems in it, mostly for users but solving some of those that I saw for modders too. I want to be able to write extensions for it that don't require me to babysit them as versions change unless something dramatic happens.

SimpleDesk was mentioned earlier on; I want to be able to create a counterpart for Wedge that doesn't require version specific hacks. I want to be able to create something that big and scary that runs on multiple versions and doesn't require me to patch it, or update its listing, just because a new version of Wedge came out.

I want to be able to port my mods to Wedge. I want to be able to write some of the other mods I've thought about over the last 2 years, except the frustration involved in writing most of them in a way that won't cause me to do support is why I didn't.
Re: Unknown's thoughts on Wedge
« Reply #40, on June 29th, 2011, 01:06 PM »
Oh, of course they could be updated, because I've learned a great deal in the last decade. But here's the thing: won't someone PLEASE think of the users? :P

Innovative is nice, but so is building something that doesn't make me feel like it's a ball and chain tying me down. I do not want to find myself in a year's time feeling burned out from having to deal with the support requests that SMF has to deal with.

Nao

  • Dadman with a boy
  • Posts: 16,079

PantsManUK

  • [me=PantsManUK]would dearly love to dump SMF 1.X at this juncture...[/me]
  • Posts: 174
Re: Unknown's thoughts on Wedge
« Reply #42, on June 29th, 2011, 06:24 PM »
Lots of interesting technical talk going on here, so I thought I'd chip in with an "end user perspective".

I just want shit to work, and that's all.

If/when we move to Wedge, I don't want to have to remember what order I installed things on the off-chance I end up with an upgrade to a mod that I installed 4 years ago (it's happened twice now...). I don't want to have the endless file-edit hell that is/was PHPBB (when we ran that) because plug-in mods was one of the main reasons we started using SMF.

Now, if "you" can manage to keep mods working across version updates, I'll love you forever; having to (re)install mods every time the host app changes isn't fun (can anyone say "SMP minecraft server"?)
« What is this thing you hoomans call "Facebook"? »

verm

  • Posts: 19
Re: Unknown's thoughts on Wedge
« Reply #43, on June 29th, 2011, 07:09 PM »
IMHO, minor version upgrades (or patches) for the same branch, i.e. ver 1, the mods should be independant of the minor changes to the codebase...

Even with major upgrades going from one branch to the next, using hooks should allow mods to be compatible (or backward compatible) unless the codebase is refactored...

But a hook is still a hook, even the codebase is totally changed then the changes to the function/class doing the hooking should be backward compatible...

I am talking nonsense is it not...

Anyway, to simplify my point, one site I administer is using SMF 2 RC5 will plenty of mods...now with SMF 2 Final, I am reluctant to upgrade since it will involved the same amount of work during the initial installation; that is checking if the mod is compatible with the version and re-install...
it would be better to simply upgrade the forum software only without all the hassle of checking the compatibility of the mods since to me it come from the same branch

[Unknown]

  • Posts: 77
Re: Unknown's thoughts on Wedge
« Reply #44, on June 30th, 2011, 10:00 AM »Last edited on June 30th, 2011, 10:24 AM by [Unknown]
FWIW, just to be clear:

I do agree that most mods should be made with hooks.  I just don't think it's possible for every single mod, and I think it's limiting.  If the average user has more than one mod that does direct edits (excluding updates), that may be a bad thing.

And again, some of the issue is "contention" for certain areas of SMF that are common to modify.  For this reason, conflicts and problems and order-of-installation are much larger problems.  Every area of contention definitely should be a hook, solving that issue.

With that said...


Quote from Arantor on June 28th, 2011, 10:55 PM
I want mods that do not have to rely on version checking. I want to avoid all the explicit checks that SMF has to make.
Hmm.  I agree that SMF is probably overly cautious with version number requirements.  I based the model on Firefox, which I think has laxed up their requirements a bit.  I'm going to save this for later.  If it had enough users, something like the Add-on Compatibility Reporter could help the situation.
Quote from Arantor on June 28th, 2011, 10:55 PM
It also doesn't discourage abandonment - mod authors, generally, want to do as little as possible to maintain their mods.
I suggest this is a separate issue.  I see no reason why hooks don't discourage abandonment (work or no work.)  I think you mean to assert that abandonment itself is less of an issue with a hook-only system.

But ultimately, I think abandonment affects everything - offhand, it doesn't seem like things that are abandoned are popular in any context, for a number of good (logistical) reasons.  They may work, but all software has bugs, and so do modifications, so abandonment is always an issue.
Quote from Arantor on June 28th, 2011, 10:55 PM
version-emulate
I don't know what this is but it sounds like a bad fix for a good problem.
Quote from Arantor on June 28th, 2011, 10:55 PM
(And if I can encourage them to do it a better way by making it less work for them, awesome.)
I think a sane approach to attempt would be to change the format from what SMF uses drastically.  Have an optional or required minimum version number, and have an optional (and never used in the examples) maximum version.  You'll probably disagree with me, but I do think there is a place for a maximum version.

I don't think a lot of mods used it, but the intention was for one mod to be installable in more versions of SMF.  But because SMF went 4 years without a major update, this didn't end up being useful.  Maybe it's not actually that useful, but there is Windows software and various other things that have BC code that is applied to older versions.

Consider, a mod that comes with a bugfix (or maybe a dependency to a common bugfix mod) for an older version, such as SMF 1.1.  This bugfix is one that, for stability reasons, was not backported to 1.1.x proper, but exists as a checkin.  This is a common thing that happens in software all the time.  The package manager was designed (but never documented) to handle this case, so that it could optionally install some backported bugfix that affected the mod, but did not really affect SMF itself much.
Quote from Arantor on June 28th, 2011, 10:55 PM
I was careful to avoid making more edits than necessary
Template edits in SMF are a huge problem, and a very separate one in my mind.  The issue there is the propagation and full-file defaulting, and also the lack of any sane way to modify small pieces.  TOX-G was designed to solve each of these problems in the simplest way possible.
Quote from Arantor on June 28th, 2011, 10:55 PM
What tends to happen is that mods which hit up the same place tend to collide, for the obvious reason
Right.  This means that they are contending for that area of code, which means a hook should exist to handle what they are trying to do.  Definitely.
Quote from Arantor on June 28th, 2011, 10:55 PM
but any mod that then tweaks the layout (or has a different layout entirely) is going to conflict.
There will always be small conflicts, when a user applies to mods that try to do separate things to the same thing.  Chaining can't always fix this - imagine a mod that converts the recent posts to be rendered using JavaScript, and updates live with a long-running PHP script (or even, possibly, a connection to something else, such as node.js, for efficiency.)  While a very reasonable use case, and possibly a useful and cool mod (but, if it requires node.js or inefficient long-running PHP, probably not something for the standard distribution) but would probably very much conflict (even if no error messages during package install) with anything that modified the recent posts in any other way.

But you note that it won't go away, I'm just giving a real-world use case.
Quote from Arantor on June 28th, 2011, 10:55 PM
1. It makes people have higher permissions than they actually need.
2. It is a major cause of people hitting mod_security errors where they throw 777 permissions at everything.
3. It is very likely also a contributor towards installations being compromised and hacked.
I'm confident that the problems are solvable.  I made changes to the webinstall.php file, and couldn't find anyone that had problems using it even on servers with mod_security, suhosin, CGI suexec, or etc.

The intention was for the package manager to automatically run the change file perms routine after installing, or else set files back, but I was concerned about some of the details (such as a mod adding files that did or did not need to be writable.)

The package manager was one of the first things I changed, and the main thing I did was move it from boardmod to a format that provided more options and detail, because of some of the annoyances I had had with boardmod.  File permissions at that point were kept the same, and quite frankly, I didn't even think about it until people started mentioning it.

Also, it was popular then (as it still is now) to run PHP in an insecure setup where PHP can always change its own files.  This was considered by many to be the most secure setup, and at first I believed them.  I understood the drawbacks of the other popular method (PHP as a single user on shared servers) and basically figured there was no way around that risk because of the db password and attachments directory.

I would probably take it more seriously now, and also more aggressively and clearly indicate the correct and secure setup for file permissions and PHP to run on any server.
Quote from Arantor on June 28th, 2011, 10:55 PM
That was partly why the krisbarteo hack in 2009 was so successful
I don't know the specifics, but it looks like it was a file-uploaded-but-shouldn't-have-been-allowed type of issue, or maybe a CSRF.  Assuming this is true, and attachments or cache are writable, you're probably screwed no matter what.

I know of another hack that people blame on file permissions, which infects files with <script> and such, generally with names like index.php, index.html, default.html, etc.  This is a client side hack (which might be delivered by a compromised HTML, jar, etc. file) that uses your FileZilla/SmartFTP/Dreamweaver/etc. saved FTP settings.

The only true way to fix this issue is to encourage the separate partitioning of uploads.  For this reason, I suggest S3 or making it the default option to enter an FTP account setup to store uploads in.  This encourages better practices.
Quote from Arantor on June 28th, 2011, 10:55 PM
While it can be 'made more reliable', I have lost count of the number of support issues that emerge every single day with SMF because of file permissions.
Incidentally, the webinstaller can do a better job at installing with the correct file permissions (and not mangling file names) than the average user would using an FTP client and the Wikipedia entry for CHMOD.  I wouldn't expect these questions and problems to go away even without the package manager.

I think the problem is that no one took the initiative to test and track down the issues.  They just figured that some workarounds were this and that and SMF could never really do it.  Add 4 years.  Kinda silly in my mind.
Quote from Arantor on June 28th, 2011, 10:55 PM
I could go on, I can find you more and more reasons to discourage file edits, and I hope this is enough to discourage mod authors where possible.
I don't think file edits are "easier."  You have to edit, and then pull out your changes.  In any significantly different codebase, this won't be preferrable to "edit the php file that hooks, and see your changes immediately, and then zip that exact file without additional testing needed."  As long as people have good examples to go from, I don't think they will lean on file edits unless necessary.
Quote from Arantor on June 28th, 2011, 10:55 PM
we make the user have to manually enable it first, to understand all the consequences. Plus, we can manage it through the repository to advise the user that manual edits will be required.
I still think you want updates applied in an automated fashion.  I find asking a user to fire up an FTP client (and what that is is not common knowledge, at least in my experience) to install updates more or less draconian.

I walked a client through installing a software that's installed in the typical draconian fashion.  She did end up figuring out FTP, but wasn't really sure on the chmod parts and I ended up having to help her.  She took notes, and learned from the experience, but ultimately I can be fairly confident she will never upgrade that software, because installing it was enough of a hassle.

That's why I see going back to the "upload the contents of this zip file" model kinda like trading in a shiny new Prius for some car from the early 1990's that gets terrible mileage and barely passes emission standards.  It's hard for me to even understand the motivation, even if you think the electric engine in the Prius is a bit complicated or causes problems sometimes.
Quote from Arantor on June 28th, 2011, 10:55 PM
But I think any more than that will be a case of putting out the tools and hoping developers make use of them
This is always the most important thing.


Quote from Nao/Gilles on June 29th, 2011, 07:36 AM
I'd like to reiterate my original idea.

Disable file edits at least until Wedge is out of beta.
If people rely on file edits when they can't find a hook, we'll never get people to get us to add hooks.
That doesn't seem crazy.  That said, if you add a hook for every possible file edit, I promise you that you'll regret it later.  More on that later.
Quote from Arantor on June 29th, 2011, 10:12 AM
Other than for file edits, why do I have to rely on versions?
A number of reasons (although if there's enough semantic hook detection, this can be mitigated.)

A well developed mod will be shipped as one version, even if there are multiple popular current branches of Wedge currently being used.  In some fashion, different hooks need to be installed potentially for different versions - consider that Wedge 2.0 adds a new hook that this mod wants to use, but in Wedge 1.x, it needs to use other hooks (or file edit the hook in, for BC.)

This can be mitigated by some sort of hook detection, but this has its own set of problems.  One option is to run plugin init code on every page view, but this has performance problems with many mods.  Another is to re-run hook init logic for every different version number internally and/or whenever plugins are installed/removed, so the logic can be updated and cached.  This has its own complications, mostly that it isn't simple to write.

I imagine you'll want a minimum version.  I can't think offhand of any system that doesn't allow for a minimum version requirement.
Quote from Arantor on June 29th, 2011, 10:49 AM
And the stuff I wrote 10 years ago... with one exception, it all still works on Windows 7. That particular exception is because of an API that was deprecated back in 2000, and naturally doesn't exist now. If you can do this on an operating system, why can't we apply the same basic techniques to programming in a higher level environment?
This is a fairly easy argument to refute.  I'm going to keep it brief because it's getting late, and I need to get some sleep, but:

1. Apps are not mods.  If your intent is to only support apps in Wedge, like Facebook apps and iPhone apps, then file edits are pointless.  That seems a silly place to aim for, IMHO.

2. Drives have had major version requirements in Windows.  Obviously you never wrote a driver.

3. Have you ever tried to change the task bar, Alt-Tab menu, or install tabs in Windows Explorer?  I have done all of these things.  They are highly Windows version dependent.

4. Microsoft has but a lot of effort and man hours into maintaining compatibility heuristics, rules, and settings in Windows.  Maybe you've never noticed them, which is a testament to them doing something right.  It's quite possible they are responsible for making your apps work, in some cases (especially where UAC might be concerned.)  Are you intending to put in that level of effort?

5. Zip tools often had major problems with Windows updates when they came out with XP, which had its own zip tool that stomped over people's existing integration methods.  ConTEXT also had some issues, although they were worked out.  I know tons of software has had to be updated for UAC as well.

6. Windows' API is full of compatibility functions.  Did you realize, every function in the API has two versions?  An "A" version and a "W" version.  The W versions were added later, and support Unicode.  The A versions support multi-byte encodings where the codepage is set properly.  They maintain both versions and it's a huge overhead.

7. There are bugs in many of Windows' APIs, some of which are documented, and must stay that way for compatibility.

8. Were you aware that Windows programs define the version they intend to compile against (although usually this is done for you automatically)?  Windows then may enable certain bugs in API calls or etc. so that it will work more like that particular version.

Are you intending to do all of these things and deal with all of these problems?
Quote from Arantor on June 29th, 2011, 10:49 AM
I want to be able to port my mods to Wedge. I want to be able to write some of the other mods I've thought about over the last 2 years, except the frustration involved in writing most of them in a way that won't cause me to do support is why I didn't.
If it's a hassle, it needs to be fixed, agreed.  There are compromises to do this without veering into an unknown space that may have its own new set of challenges not yet imagined.
Quote from Bloc on June 29th, 2011, 12:40 PM
Sounds ambitious, and in a way i see what you mean, I like to write themes or mods too, that will always work, or don't rely on anything changes etc. But i think thats an utopia, as long as the host script changes, you need to change with it. And the host script need to be possible to change, your knowledge will change, technologies arrive that require it etc. I bet your old programs, while they still run, could use updating still. Being content with it "just working" doesn't bode well for innovatism IMHO...

But I've love to see me proven wrong of course lol. :)
With themes, I think it's mostly impossible.  But I'm hoping that if they are organized right, the correct parts can be frozen, and most themes can be written to just modify all the parts that are common that don't need changes, and the main code can use overlays to apply to older themes to add new features, such as new fields.



Which brings me to "freezing."  With any API, including a hook API, freezing is important.  This is something SMF never did and it paid for it.  Facebook also (purposefully, I'm fairly sure) does not freeze their APIs, whereas for example Google does freeze their APIs.

A frozen API means that it doesn't change.  Once you sent the parameter the wrong way, you're living with it.  You're passing an id and you want to pass an object now?  Too bad.  It's frozen.  You have to create a new hook.

Some people think freezing is a bad thing, and leads to stagnation.  Making it "wrong" to improve the code means that the code will get messy, and have more weird problems in it.  This is why some developers intentionally do not freeze their APIs.

I personally prefer it, though, because it means that compatibility can be achieved in some sane way.  When I trust an API is frozen, I'm much more interested in writing for it, unlike an API that I expect could easily change within a couple months invalidating my work.  It sounds like you agree, and also want this.

Just want to mention some of its detriments so they are not ignored:

1. When freezing APIs, most people take the course of making as few as necessary.  This is because, the more you have, the more locked doors you're putting in the way of your own development.

2. These APIs also typically either have feature branches (which can be detected for) or versions, and phase out older versions or feature branches over time.  This means additional management and documentation overhead, but it's not too bad.

3. You should think hard and probably have a review process on hooks before they are finalized, so that the pains of maintaining "I wish I'd never made that hook" problems go away.

4. You need to consider more carefully what happens when a feature is heavily overhauled.  For example, suppose hooks were used in the personal message system, prior to it being changed in 1.1 iirc to have labels and such.  You have to make a decision to design the new features around the hooks, or to throw the hooks out, or do a shade of grey in between.

5. Also, with hooks, you have to carefully consider chaining, which is a more important issue than it may seem at first.  When using frozen APIs, this gets more complicated: suppose you implement an "extended" version of the hook in a new version, whilst retaining the old.  Now a user has two plugins, each using the hook, but different versions.  You have to handle the chaining.


Quote from Arantor on June 29th, 2011, 01:06 PM
Oh, of course they could be updated, because I've learned a great deal in the last decade. But here's the thing: won't someone PLEASE think of the users? :P
I don't think users like dealing with order-of-installation issues, or contention issues, or any of those things.  I also don't think they like dealing with manual edits or uploads, incompatibilities, or etc. either.  Users also don't want indirect problems like core development slowdown or not being able to upgrade because a new version has different hooks.

Trying to think only of the user often ends up ignoring a significant part of their concern.  Best to think of everyone and only prioritize the users where possible, IMHO.

That said, I know that you care about the users already from past conversations, and that's a very good thing.  I'm not knocking that at all.
Quote from PantsManUK on June 29th, 2011, 06:24 PM
Now, if "you" can manage to keep mods working across version updates, I'll love you forever; having to (re)install mods every time the host app changes isn't fun (can anyone say "SMP minecraft server"?)
This was just one of the historic "bad decisions" we made.  This came up several times while we were working on the feature.  I noticed it and considered it, we talked in the dev team about it, and the team discussed it.  But usually briefly, and the answer was always "ah, it's fine to reinstall every time."

I agree that was a bad decision, but the reality is we just didn't think it was a huge problem, and at the time, there weren't a whole lot of mods to reinstall anyway.  After that, it sorta got baked into our heads a bit, and so we stopped considering the idea of trying to retain installed mods on upgrade.

At one point, someone had proposed a more robust system, that tracked exactly what to do, installation order if necessary, and did a dry run unapplying, updating, and reapplying, and told you which mods weren't compatible that way.  I don't remember how it totally went, but we didn't do it because we figured the effort wasn't worth it.

In part, we really weren't considering the case of many mods being installed.  This was in part an over-reaction to "Supermod", which for YaBB SE was this ugly, Frankenstein thing that was a scary mess that had all sorts of fun bugs and made mod authors mass delete their mods.  Because of the issues there, I think none of us were really thinking of lots of mods as a reasonable use case at all.

Still, I'm always surprised that things like that didn't change in the last 5 years.
Quote from TechTitan on June 29th, 2011, 07:09 PM
Anyway, to simplify my point, one site I administer is using SMF 2 RC5 will plenty of mods...now with SMF 2 Final, I am reluctant to upgrade since it will involved the same amount of work during the initial installation; that is checking if the mod is compatible with the version and re-install...
it would be better to simply upgrade the forum software only without all the hassle of checking the compatibility of the mods since to me it come from the same branch
Presumably, not a ton of code has changed between SMF 2.0 RC5 and SMF 2.0, right?  So in theory, this sounds right.  I'm not sure what it means to check the compatibility; from context, I assume this is some manual process?

Let me ask you this.  The mods you have installed now, did you have to make any manual edits to install them all successfully?  I don't know if you have a bunch or if you use themes, but if the answer to either of those is yes, I presume you had to do manual edits, and you're wanting to avoid making those again, right?

I assume there is an update package for SMF 2.0 RC5.  I'm guessing it does not apply cleanly on top of your existing mods, right?



Separately, I think that Chrome handles these very well, although as mentioned, there are buggy extensions that don't work in the current version.

If you've ever built one, you'll know that it automatically packages things easily for you, and also that it uses permissions:

http://code.google.com/chrome/extensions/permission_warnings.html

These are a common concept in integrations now, and something I strongly recommend for Wedge.  I would imagine that file edits might be a permission.

-[Unknown]