Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - [Unknown]
1
The Pub / Re: Jump box and its stupid Go button
« on July 24th, 2011, 07:28 AM »
Quote from Nao/Gilles on July 18th, 2011, 10:14 AM
you could have told them to use the linktree ;)
Oh believe me, that's definitely the first thing I said.  From hazy hazy memory, I think they preferred the style where there was no linktree at the bottom (used to be the default, the "linktree" style rather than the "breadcrumbs" style.)  I'm not sure, that may no longer exist.

-[Unknown]
2
Off-topic / Re: PHP IDE for windows
« on July 18th, 2011, 08:54 AM »
It seems like Cloud9 is doing pretty well against my list.  Still missing many features, but pretty impressive.

-[Unknown]
3
The Pub / Re: Jump box and its stupid Go button
« on July 18th, 2011, 03:08 AM »
Heh, I remember when I removed the go button.  A bunch of people complained.  Turned out a lot of people, including Ben_S, used it when they finished reading a topic to go back to the list.  A strange use, I thought, but that's why it was left in.

-[Unknown]
4
Features: Theming / Re: JavaScript caching
« on July 16th, 2011, 08:46 AM »
Quote from Nao/Gilles on July 15th, 2011, 10:55 AM
The resulting index.css is 74.721 bytes, i.e. 173 bytes more, which makes sense.

Now, let's gzip both files...
Results:
First file: 74.548 -> 30.432 bytes
Second file: 74.721 -> 30.430 bytes
Well, again, it doesn't always necessarily follow logic.  But, internally, it is building a dictionary.

So even though it's less bytes, it may not fit a global pattern.  How often in the entire CSS file do you use the shorthand versions?  Probably not often.

Maybe you use:

"background-repeat: no-repeat;
background-color: #5a6c85;
background-position:"

A lot.  But you rarely if ever use:

"background: #5a6c85 url($images/menu.gif) no-repeat"

That sounds likely.  So, with the first one, gzip is able to build a larger dictionary entry, which gets used more often, saving more bytes.  It's not like gzip compresses x% always, it just compresses patterns like any other compressor.

That said, less bytes may be better for the client than less gzipped bytes, in some cases.  Especially for the browser and RAM usage.  But generally, less gzipped bytes is probably better.  In this case, yes, obviously, doesn't matter.  They probably both fit into the same number of packets anyway.

Are you aware of any clients (aside from poorly written HTTP clients in PHP and some robots) that can't handle gzip?

-[Unknown]
5
The Pub / Re: Wedge on lighttpd or nginx
« on July 9th, 2011, 08:31 AM »
It's a common configuration to have all non-existent URLs forwarded to PHP.  I know that lighttpd also supports X-Sendfile, so technically I guess you could forward ALL requests to PHP even.

Although this does require configuration, basically most other PHP packages require it too, so it doesn't seem like a hefty requirement.  Falling back to pathinfo (index.php/xyz) is easy enough, too.

Note that many nginx and lighttpd servers are configured to disallow pathinfo requests because of some gotchas in configuring them with PHP.  There are correct ways to configure them with pathinfo working, but many people don't do this.  So, pathinfo actually becomes the less universal solution.

-[Unknown]
6
Features: Theming / Re: JavaScript caching
« on July 6th, 2011, 09:31 AM »
Quote from Nao/Gilles on July 5th, 2011, 07:01 PM
I know, but it's there, so... I just use it. It's a matter of being consistent with the existing codebase. There would be too much to change otherwise.
Also, sometimes it can be helpful to know what the *intended* purpose of a variable is. I know it has helped me... Don't forget that our code needs to be readable by future devs!
I didn't say using any form of hungarian notation was wrong.  Using "userTitle" for user input and "title" for internal makes sense.  Mozilla uses a convention of "aTitle" for arguments.

But, even for a strictly typed language, type-based hungarian notation seems silly and wrong to me.  All the more for a loosely typed one.

But, just IMHO.  I know there's tons of programmers out there with different opinions.
Quote from Nao/Gilles on July 5th, 2011, 07:01 PM
You mean like <base href>...?
(man this auto strip quotes thing is kinda confusing.)

No, just a:

var smf_base_url = "http://wedge.org/";

In my experience, Google doesn't read bare links after that, e.g.:

var smf_theme_url = smf_base_url + "/Themes/default";

Obviously, it becomes more complex when those urls aren't always in the base - as with SMF, and as with some of my stuff.  I think I tried separating with + without any luck, and ended up using a htaccess forbidden rule or something (because I didn't want the separate content url indexed.)

There are issues with base href in some browsers iirc.  It generally works and I've used it before, but I know sometimes it doesn't work like you'd expect.
Quote from Nao/Gilles on July 5th, 2011, 07:01 PM
I don't even remember seeing a ready-made function for that in ECMAScript...
In TOX-G:

var x = <tpl:json value="{$x}" />;

Note that you have to wrap that in CDATA (e.g. around the whole script, as often done in SMF for XHTML compat) or use <tpl:container doctype="html5"> if you want it to be escaped right in <script> (which has text semantics.)  In attributes (e.g. onclick="blah(<tpl:json value="{$x}" />);") it will escape the html entities as well, which is necessary to avoid security holes.
Quote from Nao/Gilles on July 5th, 2011, 07:01 PM
It seems to be the case for me... In which case, why did JSE ever begin to escape them...?
I don't know, that function was created after I left.  There are valid reasons for escaping js in many ways to avoid security holes, but it seems like it does too much.
Quote from Nao/Gilles on July 5th, 2011, 07:01 PM
Gzip doesn't really matter here, you'd be surprised with the strange results I've been getting. (There's a recent discussion somewhere about the effort I went into converting some variable names to be one char instead of long stuff, and in the end the resulting gzipped file was actually longer by a few bytes... I just couldn't believe it.)
Keep in mind that repetition is what's key to compression.  Consider the following:

Code: [Select]
function show()
{
   var should_i_really_show_it = !this.is_showing();

   if (should_i_really_show_it)
      this.really_show_it();
}

function hide()
{
   var maybe_really_hide_it = this.is_showing();

   if (maybe_really_hide_it)
      this.really_hide_it();
}

It might seem like the variable names are way too long, and they are (from a this-code-is-ugly perspective.)  But really, the biggest problem for compression is that it isn't very repetitive.  Consider instead:

Code: [Select]
function show()
{
   var is_it_showing_now = this.is_showing();

   if (!is_it_showing_now)
      this.really_show_it();
}

function hide()
{
   var is_it_showing_now = this.is_showing();

   if (is_it_showing_now)
      this.really_hide_it();
}

Yes, the variables are shorter.  But, the more common pattern may compress better.

One of the important things minifiers do is create patterns.  For example, doing "if (x) {} else y();" may actually be better than "if (!x) y();" in a long document that uses "if (x) {" a lot and uses "} else" a lot.

Potentially, but not necessarily.  Without actually testing, the cases can always be strange, and small scale experiments are rarely accurate.

Anyway, I was guessing that using \ns might gzip better, at least because the pattern after the \n and including it may be more likely to match (such as "\n     <div".)  Obviously, the \ does muck this up and so it might not really compress better after all.  Certainly it's the same number of bytes whether a newline or n is escaped.
Quote from Nao/Gilles on July 5th, 2011, 07:01 PM
Ah, would be swell if Apache added support for 7z or even RAR... :lol:
Well, recall that the iPhone 3GS was able to load pages much faster than the 3G.  This wasn't because they gimped the network for the 3G, but because the processor was more capable to deal with it.  Engines like 7z, rar, and bzip2 achieve better compression ratios but at the cost of more cpu, which can be a problem (if dynamic) on the server side, and can of course be a problem on the client side (e.g. for mobile.)

Anyway:

https://bugzilla.mozilla.org/show_bug.cgi?id=173044
https://bugzilla.mozilla.org/show_bug.cgi?id=366559

AFAIK rar is encumbered so I wouldn't hold my breath for it.
Quote from Nao/Gilles on July 6th, 2011, 12:01 AM
Just Google it ;)

I suppose strtr() isn't that slow anyway...
Actually, it is.  On long strings, str_replace can take only 15% the time, and on short ones 30%.  The situation was reversed in PHP 4, which is why I used strtr a lot in SMF (I also prefer its syntax.)  In fact, in some cases preg_replace may beat strtr, I suppose, based on my benchmarks.

I think that in that PHP fork that was posted here, the guy sped up strtr.  Clearly there's room for improvement.

By the way, json_encode, on my setup, is in fact even faster than addcslashes (which by the way, is usually faster than addslashes, even with the same character list.)  Haven't checked its memory impact, though, would probably need to xhprof that.
Quote from Nao/Gilles on July 6th, 2011, 12:01 AM
I'm getting very annoyed by the constant changes in my CSS. I'd really like to call it quits and commit it, but I'm scared most people will think it doesn't look as good as a stock SMF2, ah ah...
Heck, I made many changes to the visuals this week really. Even the windowbg divs have finally lost their border... (I'm not kidding. I was adamant this border would be in the final design... Until I decided it wasn't needed.)
Ehh... I suck at design which is why I left the HTML and CSS stuff mostly alone in SMF.  The nice thing about a versioning system like svn is you can always svn merge -c -123 and undo a commit.

-[Unknown]
7
Features: Theming / Re: JavaScript caching
« on July 4th, 2011, 10:15 PM »
Quote from groundup on July 4th, 2011, 04:21 PM
I think minification is more about saving space in the cache. Especially for mobile devices.
In my experience, reducing HTTP requests has a significant effect even on desktops.  And since it normally seems to cut 20%, and mean that I'm not afraid of leaving potentially concerning comments all over my js code, it seems good for inline script too.

One of the "good" reasons for using inline script is when it's only used on the one page, it's an uncommon page, and you want to reduce the HTTPs even further, especially if the script is small.  But lowering the network consumption is a good thing, because if I can reduce the whole page by 20% (which I can't, more like 8% it seems from a standard HTML page even with some embedded script), without any additional CPU cost, that can potentially be a good savings both for user and the network operator who has to be $5/megabit or whatever.

I've become more concerned about these issues as more and more US companies have been limiting their users' bandwidth, which I hate.

-[Unknown]
8
Off-topic / Re: Unknown's thoughts on Wedge
« on July 4th, 2011, 10:09 PM »
UAC: Well, no.  UAC is very different from, say, sudo or etc.

UAC hits you with a heavy hammer.  Unlike sudo and most other systems, it asks you *every time*, resulting in user training.  It's also for anything that isn't something a standard user can do: for example, UAC would require a password prior to moderation.

SMF does require the password (mostly as a last-effort against CSRF or session fixation), but only for logical administrative functions - editing profiles, the admin center, etc.  At least it used to.

But, I don't need to type a password or confirm a prompt to go into an admin-only board, or post a reply to a locked topic, or etc.  That's what UAC does, and I don't agree with it or like it.  That said, being able to opt into that situation seems interesting.

Permissions:

I think I've talked about this before, and how roles make more sense.  Looking briefly at that super long post, it seems like you're doing the right thing: create "groups" of permissions, aka roles, and assign users (or groups) to these roles.

It's really how I meant for groups to be used, but ultimately, it's confusing.  When you start with "Guest", "Member", and "Administrator" it is not natural to think of creating an "Attachment Poster" or "Poll Starter" group.  It's the same context problem I was talking about before.

If mods created default roles on installation, and SMF/Wedge came with a healthy set, this could be a good thing.  I know I posted at length about this on SMF somewhere, and I can't remember some of the details of the system I tried to think out.  But in general it's a lot clearer than "additional groups."

It looks like that's what you have.  Also the own/any/all thing, dropdowns make sense.  I wasn't sure about the UI ever, and was initially trying to go with checkboxes with deny.  I wanted to expose the option to allow people to, e.g., lock any topics but their own (which can be done with deny) because there were interesting use cases people had asked for that required this (even though it was a <1% type of thing.)  Probably this was a mistake, because deny is something that users just don't generally understand well.

I think instead of board permissions, you might have roles be "global" always, and when you assign roles to a group or user, make the board-specific association there.  For example, when editing "Global Moderator" (a group), I might set them to be in "Standard Users" for all boards, and "Attachment Posters" for only boards (or departments or galleries) x, y, and z.  And I might put them in some other role for all boards except a, b, and c.

In fact, denying them a role may make more sense than having permission-level denies, and may work for users in their heads.  I'd have to talk to a few users to figure that one out.

The interface could offer roles for board-specifity based on them having board permissions.   Same with gallery or departments.

Then once you've "built" the group, and tested it by impersonating the group, it's much easier to assign and understand what will happen, because that group is all on one page.

Ultimately, in the same token as file editing, I think that "additional" groups should be something most people almost never use, if possible.  Having seen users try to use them, they are only confusing to them, *especially* with the whole Regular Members/Ungrouped Members conundrum, which needs to be gone yesterday.
Quote
* PayPal, because I take the view (much, as I think the team did at the time) that anything payment related, I'd rather have that in the core than a possibly unmaintained mod, for security purposes
I'm not saying whether I'd take them out of the distribution (although, this I would, but probably for legal/liability related reasons), but that I would remove them from my own install, where I'd never use them - as a general clarification.

I understand and agree, to a point, with your argument that it's better if it's more strongly maintained, since it's an important feature.  That said, I've never been to or used a forum that requires payment for anything or in any way related to the forum, aside from simplemachines.org.  I've used forums related to paid products (such as hardware or software or physical goods or even services), but none of these seem to "fit" with the payment features in SMF as I understand them.

So to me, in this particular case it just seems like additional risk for, what, adult content forums?  Those were like specifically what I didn't want to cater to.  If I could add a feature that would make those sites less likely to use my software, I'd consider that a big plus under the "reasons to add this feature" column.

I'm also not sure it's a benefit to end users, since I would assume it can only encourage making them pay for access in situations where that may not make sense.  But ultimately, that's a problem for the free market, so not a big deal.
Quote
* HiveMail... not sure what you mean? Certainly there aren't any mods named that on sm.org.
HiveMail was a mod to integrate some web based mail solution into SMF.  I may be remembering its name wrong.  It was actually one of the first paid mods.  I thought it made it so you could give each and every user of your forum an email address, automatically IIRC.  Or something like that.  I never looked hard at it, and I think just helped the author some?  Memory is very fuzzy.

ViewFile: it makes my security hairs stand up on the back of my neck.
Quote from snoopy-virtual on July 4th, 2011, 04:13 PM
In all the time I have been giving support, I have seen some people in cheap servers with no FTP access nor a good control panel, so the only way they have, if they ever need to edit a file, is using this feature.

If file edits are going to be ever needed I would even suggest you could extend that feature to all the files (not only the Theme files) for that people without FTP.
I realize there's a "thriving" community of forum-only hosting.  That said, I personally feel that if the host doesn't want to give them any access to the files, we shouldn't either.  Especially if the host is doing something like BoardNation was, with a shared sourcedir setup.  Then it could even be dangerous.

-[Unknown]
9
Off-topic / Re: Unknown's thoughts on Wedge
« on July 4th, 2011, 11:11 AM »
Quote from Arantor on July 4th, 2011, 10:02 AM
Let me explain what exactly my edits did, and I'll let you judge for yourself. FWIW, I'm of the view that these are acceptable, not necessarily desirable.
I think they're fine an all "hookable" in some fashion, although whether hooks would necessarily be forethought for all these areas is uncertain.  Th only area I see a theme potentially wanting to touch is the IP one, and probably not.
Quote from Arantor on July 4th, 2011, 10:02 AM
(and yes, I did account for that in the maintenance... I think I did, anyway... have to check that now, it's been a year since I wrote it)
Ah, good.  While I think no one uses that feature (at least they didn't used to), I think it's a good feature.  It came from YaBB SE and probably even YaBB, originally.
Quote from Arantor on July 4th, 2011, 10:02 AM
Something like that would have to be done as manual edits, I don't think there's any way around that - but on the other hand, something like that should be in the core anyway.
Still don't agree that the core should have a working kitchen sink that churns out boiling hot and cold water, but I do agree with the decisions that led to that particular mod being integrated (I didn't do that one but liked it after the fact.)  I think it was a popular YaBB SE mod.
Quote from Arantor on July 4th, 2011, 10:02 AM
(e.g. SlammedDime's SimpleSEF periodically makes sure it is the last hook called - though I recognise that it's possible a second mod will attempt to do the same and cause issues that way, but I gotta say that's very much an edge case there, order of execution is not that much of an issue for the *majority* of mods)
Well, edge cases are important.  Even if just knowing about them and documenting them.  People are professionals not because they don't make mistakes, but because they prepare for them in advance.  I'd rather know what can go wrong and know when it goes wrong than just be confused.

In this case, I think I've seen before a "hook weight" where you can basically say "I want to be first", "I want to be last" and sometimes even "I don't care [so put me in the middle]."  Even DOM events work in this way, with capture and bubble phases.

In practice, most people (especially people using jQuery, which likes to rename everything) only use bubbling.  But the DOM has both models.  AFAIK, no one has proposed taking it out even though almost no one uses capturing (the "I want to be first" one.)  In fact, jQuery doesn't even expose an interface for capturing, neither does Prototype, nor Dojo.  Basically only Closure does, and no one uses it.

Of course, it doesn't help that IE doesn't support capturing.

Still, with some people going on the warpath on things like XHTML that no one uses or uses properly, because IE doesn't support them anyway, and wanting to remove them from the web, capturing has been left untouched.  Because it is necessary, even if only 1% of the time.
Quote from Arantor on July 4th, 2011, 10:02 AM
Yet there are a great many mods that interfere with version updates and vice versa.
Well, I don't remember the minor version updates being that major.  A mod has to touch, what, like less than 6% of the code base at most, on average?  It's surprising to me if the majority of minor version updates interfere with mods (not because they interfere with each other, but the actual updated parts.)

For contention areas, like new permissions, yes... there's really potentially no way around those without hooks.  That said, in most of my mods, rather than adding an index to an array, I'd add code afterward that would do e.g. $actionArray['x'] = array('y', 'z');.  While "ruining" the style, this didn't ever break and my mods were fairly low maintenance.

In fact, I can't remember ever having to make major changes to my wikilinks mod, for example.

So my point is that it shouldn't be that there are "high maintenance" areas where it's hard.  Those areas, if they exist, should certainly be hooks.  I know this was something, when I was around, we just hadn't gotten to yet.
Quote from Arantor on July 4th, 2011, 10:02 AM
That's the problem: it's all in the database, and the upgrader doesn't deal with it properly. The file is still present, though, it just contains the timestamp of the last install. Quite *why* it does that, I have no idea.
Oh, I remember.  Originally we set out to move to the DB and that was it.  Then we got concerned about the issue of someone uploading an upgrade package, and we wanted the installed.list in there for some reason.  I can't remember the details.
Quote from Arantor on July 4th, 2011, 10:02 AM
You can't do it that way: remember we talked about multiple versions being handled in the same package? There's your reason not to do it that way. Imagine you have a mod that states it supports 1.1.13 and 2.0 RC5, and you're on 1.1.14. Which set of instructions should it use as a 'default' fallback?
Well, you can pick the one that is most similar.  Starts with the most same characters, or matches the "lower than this" check but not "higher", or else matches the "higher" and is the lowest.  I don't see the point of picking a specific version to emulate when it seems as if the software can figure this out itself.

Especially when I do expect most mods will always be just a single version [range].
Quote from Arantor on July 4th, 2011, 10:02 AM
Board permissions confuse a lot of people and 2.0's move to using profiles for boards is even more confusing. I know the entire setup needs to change but I'm not yet sure which way to go for the best.
I'm not sure either, but I'm certain it involves impersonation or in other words "sudo."  Bugzilla, for example, does this and they only have like 7 permissions.  That said, its permissions also confuse me (because there are all sorts of overlaps, I feel like really it would be easier if there were more permissions or something...), but at least I can see what they do by impersonating someone.

And as much as I hate UAC the way it works in Windows, I like the concept of opting in to having lower privileges for a period of time.  It's something I probably would use, especially e.g. on a forum like Yourasoft, where I might not want to have moderation privileges or be able to see all boards (both were issues there, and we eventually used a shared admin account, which is a horrible idea from a security perspective.)
Quote from Arantor on July 4th, 2011, 10:02 AM
From my perspective, the calendar as it stands is not that useful, so having it in core is not necessarily the smartest move, but if it were to be more useful, there would be more reason for it to be present.
I would still take it out (if I ran a forum) and just drop a link in my menu to a Google Apps calendar (if I even needed a calendar.)  I would also remove PayPal / any payment stuff (in fact, that would be the very first thing I'd do) and if that HiveMail or whatever mod got integrated I'd remove it too.  I'd remove the moderation center, dumpdatabase, any friendly theme editing features (and especially the viewfile thing in the error log viewer), and definitely the "block me from logging in whenever a hacker wants to spam my account to lock me out" feature which has inevitably been added in order to compromise my security.  I would use none of these things, and they could only possibly reduce my security at worst, and insignificantly decrease my forum's performance at best.
Quote from Arantor on July 4th, 2011, 10:02 AM
I don't think there's any way to avoid that, though. Every time someone writes some code and releases it, it adds to the total substance of what's available - and every time that happens, there's one or more people out there who won't roll their own version of the same. From my POV, I see it as priming the pump for the most part, because I know others out there will think of ways to expand on what we come up with, and I know I won't be writing every possible permutation of mod either, so others who want it differently will invariably come up with their own spin on it.
Well, it's not necessarily always a bad thing.  I'm just more of a "wait and see" kind of guy for things I don't want.  I love building things I do.

I think a great example is WikiLinks.  I liked that mod, and I thought the feature rocked.  Ultimately, I didn't feel it was right for release, and there were a few complications with it... but it seemed like a perfect mod to me.

-[Unknown]
10
Off-topic / Re: Unknown's thoughts on Wedge
« on July 4th, 2011, 07:01 AM »
Ah, I see.  Well, there's ups and downs of that.  A reasonably easy workaround is to include a (small) file on loadSettings or what have you, and then from there load additional file(s) as necessary.  This won't have a huge perf impact.  But yes, specifying a file makes more sense.

-[Unknown]
11
Off-topic / Re: Unknown's thoughts on Wedge
« on July 4th, 2011, 06:32 AM »
Quote from Arantor on June 30th, 2011, 06:46 PM
It was mostly a statement in response to Unknown's question about upgrading from 2.0 RC5 to final being a full update (which it is, unless you're insane enough to go through and make the changes to each file by hand, as I did in Wedge's case)
Or try a diff between the two release trees, which probably wouldn't apply cleanly in most cases.

To me, that's more caused by the major changes.  In the case of SMF 2, if the API to make database queries, or all that string stuff, etc. changed between releases... you're screwed.  Doesn't matter if you're writing a plugin, widget, modification, or even a poem.  It means your stuff is wrong and has to be rewritten now, no matter what.
Quote from Arantor on June 30th, 2011, 06:46 PM
Ah, that means I've been reading between the wrong lines.
I try to mean what I say and say what I mean.  If I ever do otherwise, please call me on it.  I find reading between lines to be an dangerous pass-time at best, so I try not to make people do it.
Quote from Arantor on June 30th, 2011, 06:46 PM
Yes, that's the plan. I look to SimpleDesk on this one: there are some places I do actually do template edits in SD 2.0
In contrast, because of themes, I think template edits are pretty much "always wrong."  I tried to solve this as categorically as possible in TOX-G, even allowing alters to completely replace an existing template.  I realize file alterations might still be needed in some cases, but I'm hoping that the average user will have zero template file edits, because it pretty much destroys theming.

I also realize a good majority of mods are based on themes, which as I said, can hopefully all be done in a "clean" way.
Quote from Arantor on June 30th, 2011, 06:46 PM
the track-IP screen or the manage-attachments screen unless they had very, very good reason (and SD does, in both cases) - and since they are uncommon templates, I'd never had a conflict.
Hmm.  I retract my statement only a few lines above this.

In this case, file edits don't seem horrible at all.  While I still think themes should be able to modify administrative areas, if a couple of templates can be used to control generate look (without forcing an exact HTML structure, which is what I always didn't want to do), then I don't think there's generally any good reason for a theme ever to change the meat of an administrative section.

That said, if they used templates cleanly, it might possibly be avoidable there too.
Quote from Arantor on June 30th, 2011, 06:46 PM
Not all things are expressly hook points as we normally think of them.
Well, in terms of TOX-G, templates are "hooks" as well.  There are many cases of these.  All have costs, but most are minimal.  A css class is not too expensive, nor is the function call incurred at runtime for (defined only, altered or not) TOX-G templates, especially since this call is static and can be optimized by e.g. an accelerator (unlike dynamic hooks in code, which typically use call_user_func_array or etc.)

Also as I mentioned before, using Exceptions can add more hooks, because it adds the possibility of wrapping the HTML output of SMF/Wedge/etc. in another software (as long as exit is done in cases of file or xml output.)  In a way, this is a hook as well.

Another place for hooks (but this has a high version requirement as a cost) is e.g. database functions and views.  They don't actually allow renaming or hooking easily, but potentially they could be used for hooks (e.g. instead of something liek query_see_board.)
Quote from Arantor on June 30th, 2011, 06:46 PM
My point here, I guess, is that mods can be written with other mods in mind, if the author chooses to be careful about it.
Well, I agree with designing in a way that this is not necessary to think about.  Just like security; anything that can be made automatic is better that way, as long as it doesn't have other downsides.
Quote from Arantor on June 30th, 2011, 06:46 PM
(It would also be quite hacky, I think, but it would certainly solve some of the issues.)
Sure.  Although that can't do everything.  Imagine if the recycle bin functionality were to be made a mod (in fact, I'm fairly sure it was at first.)
Quote from Arantor on June 30th, 2011, 06:46 PM
it should be possible to do some of it in the Wedge ecosystem, and it was more a comment to encourage people to stop and think for a moment.
Well, possible and practical aren't always best buds.  In this case, I suspect Microsoft has a couple more employees to put on the problem than probably Wedge ever will, which was the point I was trying to make.
Quote from Arantor on June 30th, 2011, 06:46 PM
(This sort of behaviour is not unheard of even in the forum ecosystem. Whether it's desirable is another matter entirely.)
Well, I agree the current package manager leaves a lot to be desired.  Separating it isn't necessarily a bad thing, but leaving it alone without improvements might be.
Quote from Arantor on June 30th, 2011, 06:46 PM
But it's hard work because of the nature of changes in SMF between the two branches and in all honesty, I'd personally rather have not bothered with the dual packaging. (In fact, I shied away from making mods for both branches at once, simply because invariably I had to write it twice, because everything was different, most importantly $smcFunc vs db_query)
Well, again, I feel this was a separate problem.
Quote from Arantor on June 30th, 2011, 06:46 PM
Users, generally, don't seem to have a problem with mods being in separate packages for different versions
Hmm, users I've talked to (before and since) generally seem annoyed by it, although perhaps more often than not it's because they can't find one for their version.
Quote from Arantor on June 30th, 2011, 06:46 PM
what hooks it had available to use, and thus what hooks a given mod could use, while the main site would know all the hooks in every version.
Just because a hook exists doesn't necessarily mean everything.  What if you release a version with a broken hook (accidentally)?  Do you consider this a critical update, and release a patch soon after (as with a security hole) or do you let it sit for the next usual release (potentially causing confusion)?
Quote from Arantor on June 30th, 2011, 06:46 PM
It was suggested before that SMF's mod site could attempt to perform installations on different versions and see if the file edits were successful
That sounds possible but like a potentially heavy hammer.  That said, separating the package manager out a bit (not necessarily completely) and making it run via command line would probably improve things there and elsewhere:

  - automation becomes much easier.
  - admins who don't want to type in a sftp password or anything can do it through cli.
  - less concern about "apache died in the middle of the operation" issues.
  - obviously it would still need to be able to run from web.

If that were the case, the mod site upon upload could potentially run:

php /home/smf/tools/packman.php install --dry-run --install=/home/smf/versions/smf_2/2.0/

So while I still think the concept of running against every version is overkill, the concept itself may not be awful, even to at least verify the current version works.  In fact, even with hooks this might be an easier method than keeping a (probably out of date) list of hooks, especially if there are many.

I know near the tail end, I started to make the status tools and upgrader, etc. cli friendly.  Can't recall how many I got to.
Quote from Arantor on June 30th, 2011, 06:46 PM
I would point out that it is our intention not just to throw out a release and then declare it feature frozen for the life of that branch. We always planned to handle it iteratively, in a kaizen-style of development whereby each version adds something as well as just bug fixes, some method of improving how we do what we do - instead of just giving users a 'this version just fixes some bugs' reason to update (which is a push factor), we want to give them some pull factors too.
Then you need to at least do code review.  Something has to happen or eventually, things will be changed wrongly in that model.  AFAIK, Firefox (now) and Chrome have a lot of red tape involved in the process so that it can happen fast.
Quote from Arantor on June 30th, 2011, 06:46 PM
It was a file being uploaded that was able to be executed. Which then tries to infect any PHP file it can modify.
On "secure" suexec installations this would be all files, so you're screwed in this case.  In insecure nobody installations, this could potentially be many files or even other accounts on the server.  So you're screwed that way too, even without the package manager needing things writable.
Quote from Arantor on June 30th, 2011, 06:46 PM
Order of installation is an issue that, really, only comes about because of multiple mods doing file edits in contentious areas
Not true.  Two plugins hooking the same hook can also cause issues, e.g. if one processes out something and the other one needs it for some other reason.  It's rare, but at least with file edits, they fail rather than have weird edge-casey problems.
Quote from Arantor on June 30th, 2011, 06:46 PM
people are prepared to pay others to install mods does bother me slightly.
People also pay for upgrades and installs.  I usually did them (or tried to) for free, but only when I had time.  At work, we are paid to install other software - like vBulletin or osCommerce or even Bugzilla.  Even if they are easy to install, sometimes people want someone else to deal with it and polish it up.

That doesn't seem wrong to me, in any case.  That said, if it's becoming necessary, that seems bad.
Quote from Arantor on June 30th, 2011, 06:46 PM
they're no longer edits.
Well, unless major changes happen again, as did with SMF 2.0.  What if they separate out the core, and now all the syntax for everything has to change again?  Are these "maintenance" areas really big problems between e.g. 1.1.1 and 1.1.2, etc.?
Quote from Arantor on June 30th, 2011, 06:46 PM
the ability for a hook to load a file when necessary.
I've not looked at SMF or Wedge's hooks, but how can this not be possible?  Doesn't a hook run code?  Can't code include files?
Quote from Arantor on June 30th, 2011, 06:46 PM
There is, buried in the depths of the upgrader code, some facilities for this but I don't think they're enabled and even if they are, I don't think they work properly.
Yeah, I know it was there, initially it wiped out installed.list IIRC.  I think we moved to a database to remove the requirement of that file being writable, and may never have fully moved everything over.
Quote from Arantor on June 30th, 2011, 06:46 PM
(much as I find the idea weird: why run something without learning a bit more about it?)
How much do you know about the internals of PHP?  Do you know what the zval cache is?  And even if you probably do, do you think most PHP programmers do?  I don't necessarily think it is weird, it is compartmentalizing.  Definitely it's better to learn about it, but time is required.
Quote from Arantor on June 30th, 2011, 06:46 PM
Users should check that mods have been updated for 2.0 by looking at the mod's page. Especially since each RC has brought some interesting changes with it (as it happens, there are behavioural changes between RC5 and final that some mods will have problems with)
Which means, in other words, that they were betas.  And if the last RC and the final and major behavioral changes (which I gather it did), then basically a release candidate was never made.

I'm sure I made mistakes in this area too, although I think the general rule was that we branched the next release when we RC'd, so theoretically the major changes were happening in the next release at that point.
Quote from Arantor on June 30th, 2011, 06:46 PM
Oh, and before I forget, as it's relevant. You asked what version-emulate was.
This sounds like a bad idea.  I would rather just say "hey, this version says it won't work, want to try it anyway?"  I even thought it did that.... but I guess it probably doesn't.
Quote from Arantor on June 30th, 2011, 06:46 PM
I am only too aware how users are becoming 'trained' to accept stuff.
You can change whether you ask, though, especially depending on settings.  For example, for most permissions Chrome never asks.  They may ask in the future (without requiring extensions to change anything) if they need to.  This gives Chrome all the options without a lot of work from extension authors.
Quote from Dragooon on June 30th, 2011, 08:38 PM
That, and standardizing data loading, SQL querying etc.
Which if done wrong (as many people do) can make optimizations extremely painful to deal with...
Quote from Arantor on June 30th, 2011, 10:20 PM
SMF's permissions system allows for 'in a board' and 'not in a board' permissions, but nothing more configurable or flexible.
This always felt like a hack to me, actually, and I never felt completely comfortable with the way board specific permissions kinda shook out.  They still confuse me, which is a bad sign.
Quote from Arantor on June 30th, 2011, 10:20 PM
Right now we're arguing over how big the forest in the landscape is, or the size of the cottage. We're not arguing that the picture needs sky and land, and that it needs trees and maybe that cottage - only the relative sizes and the fine points.
At least we're not (or at least I hope I'm not) arguing about the color of the bikeshed.
Quote from Arantor on July 1st, 2011, 12:15 PM
but also so will breaking them up into manageable chunks (that can be manipulated in the subtemplate loader now)
Does SMF's system yet allow for multiple subtemplates to be used on the same page?  Example: "poll", "poll", "calendar", "post_list"?  I think I mentioned on SMF I have since moved to this system (and TOX-G uses it too.)
Quote from Arantor on June 30th, 2011, 10:20 PM
SimpleDesk is another similar scenario: I don't see anyone else ever writing another helpdesk for SMF - not only is it pretty niche, but I think I did enough of a good job with SD that another isn't needed unless SD is wholly unsuited to a given task.
Actually, a reason not to have things in the core also is attack surface.  From a security perspective, I want to remove the calendar from (at least my own installs of) SMF because I don't use it, and it doesn't have a small SLOC.  The more code, the more potential bugs, and the more potential security flaws.

That's why I've always wanted the calendar to be a "bundled mod."  It's also part of the reason I like file edits, to a degree, because having code that isn't run when a setting off is nice, but having code that can't even be run unless I twiddle the file permissions is nicer.

But, I know that most people are not so "don't even use their real name online" paranoid as me when it comes to privacy and security.
Quote from Arantor on June 30th, 2011, 10:20 PM
But I find that's limited mostly to the 'new functionality' add-ons, not the 'modifying existing functionality' ones, I foresee there will always be new ways to do that, and people always wanting to do so. But I figure if I attack the most commonly requested mods, to deal with the general cases, it doesn't negate anyone else doing it, it just means that people can focus their attention on new things instead of finding existing things to rehash over and over, if that makes sense.
Sure, except it can narrow the mindset.  For example, consider the general concept of lesscss:

First, the code was written to be "post-processed."  This is nice, and the templates are easy, but it makes development kinda slow, especially if you don't have ruby set up in your webserver.

Then came along node.js, and lesscss was rewritten in js.  The same code now runs in browser (for development) or on dist (for post-processing prior to production.)

Whereas rewrites are often bad things (as noted with YaBB SE -> SMF was a gradual rewrite, not a from scratch one), in this case a context change was pretty much required.  The Ruby one made sense, but is now deprecated and replaced by the js one.

Now consider if Apache had released, as part of the Apache distribution, a "less" module and used the Ruby code (or even ported it to C) to serve the converted CSS through Apache.  Even though the js solution is better (because it works everywhere, and combines well with minification), it probably wouldn't have happened, and people would be complaining right now that there's no nginx version of less.

-[Unknown]
12
Features: Theming / Re: JavaScript caching
« on July 4th, 2011, 05:11 AM »
Quote from Nao/Gilles on July 1st, 2011, 02:17 PM
I originally minified everything together, but performance was not any better. Probably a bit worse IIRC. Plus, it had other issues linked to it. Once I started doing files separately, it went better.
Hmm, this is not the same as my experience, odd.  I just combine with newlines between the files, which generally solves all the problems I can think of (some people don't add newlines, which means Windows-style files with a comment at the end or a missing semicolon can have issues.)
Quote from Nao/Gilles on July 1st, 2011, 02:17 PM
Also, performance is not very important at the minification stage.
Sure, unless you're debugging/developing.
Quote from Nao/Gilles on July 1st, 2011, 02:17 PM
Commenting JS files should be mandatory. If only to help future developers get into the groove :)
Well, with minification, yes.  Although, I see the JS has changed markedly since I last touched it.  I've mentioned before my dislike of hungarian type notation.
Quote from Arantor on July 3rd, 2011, 01:57 AM
Oh, I remember that discussion now. It was about what JavaScriptEscape did, and why it was necessary to call it for URLs - because there were all kinds of bad URLs getting into Google (namely the one indicated with %msg_id% in it)
Ah, I've seen this too.  I think the best way (and the way I use) is to just use a common base url variable.  I think it's better to json encode values (and not have to deal with the quotes and escaping and such) than this JavaScriptEscape business.  Note that json_encode escapes / as \/ to avoid the </script> issue, which is cleaner and more obvious than '<' + '/'.

Also AFAIK Google appears to often aggressively detect URLs, so even escaping the href probably does no good (at least in my usages it didn't.)

Last of all, \t can be cleanly represented in js and \n can be escaped as in:

var x = '\
   <div>\
     Hi\
   </div>';

So if JavaScriptEscape is kept, it's probably better to just escape the newline rather than making it \n, if concerned about readability.  Probably gzips better.

Of possible interest to this topic, I've been briefly experimenting with a plugin to TOX-G that adds minification to inline js/css (as long as it doesn't have any ifs/etc. in it) and minifies some parts of the HTML (all of this done in the cached template, so runtime speed is not affected.)  Initial impressions seem like it's mostly a waste of time (at least in my inline script tags, which are not common), but offers a small benefit.  I haven't been messing with it much since.

-[Unknown]
13
Off-topic / Re: Unknown's thoughts on Wedge
« on June 30th, 2011, 10:54 AM »
Quote from Dragooon on June 28th, 2011, 11:38 AM
So you didn't go to a professional university?
Oops, sorry, almost missed this post.

Well, no, I didn't.  Some life happened and other complications got thrown into the mix.  There are a few things I didn't get to do during that period that I had originally intended to.

Don't get me wrong, I didn't work on SMF instead of going to a university/etc.  Rather, life happened, and those weren't immediate options, so I worked on SMF instead.  Ultimately, it was a great experience, and no matter what mistakes I made or didn't make, I grew a lot from it.

Although I think college/university is a fairly important thing, I did luckily study a lot of subjects in high school, and since then I have spent a lot of time keeping up on RFCs, recommendations, other project's management and code review practices, etc. in order to keep myself versed.

If it weren't for those things and SMF, I definitely wouldn't be where I am now (professionally.)  It's really impossible to guess whether having gone to college/university would have changed that, considering how much I learned from working on SMF... IMHO.
Quote from Paracelsus on June 30th, 2011, 10:30 AM
Quote from Bloc on June 29th, 2011, 10:28 AM
But maybe you should back up abit...what exactly IS the purpose of Wedge? A forum alternative to SMF with extras? or a "soon-to-be-core" script that can accept plugins, and just happens to be a forum in nature..? Not saying one or the other is better in any way(done my share of making SMF into something more for example lol) but whatever direction you are headed will also influence the question of using file-edits versus hooks/plugins.
Wise words.
Yes, ultimately, if they just want a forum that supports "apps" like a gallery, a portal page, etc. then it's all a moot point.  I personally wouldn't be satisfied with apps, but it's a question of audience, I suppose.
Quote from Paracelsus on June 30th, 2011, 10:30 AM
If this is the way for Wedge, I say go for it... maybe you won't get the same level of contributions from external coders (since it's a more "controlled" product), but you'll make your end-users and those who administrate the forums very happy. ^_^
I think that administrators can be made happy without having a rigid product.  Ultimately I see both extremes as "unhappy administrators" just for different reasons.

-[Unknown]
14
Off-topic / Re: Unknown's thoughts on Wedge
« on June 30th, 2011, 10:00 AM »
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]
15
Off-topic / Re: Unknown's thoughts on Wedge
« on June 28th, 2011, 07:57 AM »
I'm 25, so I guess I was about 17 when I started working on SMF.  Certainly have learned a few things since then.

Dunno about whizzkid, essentially I spent the couple years after high school working on SMF before I got a job.  It's much easier to get a lot of things done when you don't have other obligations etc. yet.  More a function of circumstance.

-[Unknown]