Wedge

Public area => The Pub => Features => Topic started by: Arantor on October 4th, 2011, 12:17 PM

Title: The calendar
Post by: Arantor on October 4th, 2011, 12:17 PM
Been thinking about this quite a bit today, not entirely sure why.

On the list of plugins I'd made, recurring events and event registration/RSVP came up fairly high on the list for calendar plugins.

But what I'm wondering is about unbundling the calendar. Our stance on it has always really been that if we give the calendar a real use, it can stay - and I know it can have plenty more uses than it currently has, but I'm wary of putting all that into the core. I don't know why I'm so reticent about it, there's really no reason for it.

Now that the plugin manager is basically functional, though, there's no real reason why I can't bundle the calendar into a plugin and have that developed separately. I guess there is a part of me that's enthusiastic about segregating functionality, especially since the calendar is not the fastest thing in the world (I'd leave birthdays in the core, though!)

It would, interestingly, also ensure that several hooks exist and are proven to work (notably integrating stuff into the post dialogue, validating it on reception and throwing it back for an error)

Thoughts?
Title: Re: The calendar
Post by: Dismal Shadow on October 4th, 2011, 02:47 PM
Make it a plugin, sync with Google calendar maybe?
Title: Re: The calendar
Post by: billy2 on October 4th, 2011, 03:08 PM
I think making it an 'addon'  :whistle: , satisfies a previous thread where most were not bothered about it being in the core.
 
http://wedge.org/code/6126/calendar/
Title: Re: The calendar
Post by: Nao on October 4th, 2011, 05:01 PM
I could care less about whether the calendar is core or not. However, if we make it a plugin, it could be interesting to implement 'dependencies' in the plugin system (if not already done...), where one plugin would only be enablable (technobabble?) if another one (specified by ID) is there.

(Oh, and official plugins should have the 'Wedge' ID, BTW. Calendar would be <Wedge:Calendar> for instance. Or <wedge:calendar>. (I'm all for lowercase everywhere. (And parenthesis.)))
Title: Re: The calendar
Post by: Farjo on October 4th, 2011, 05:58 PM
My lot use the calendar - it's one of the pluses of SMF. From forum owner perspective my only reservation about it being a plugin is that it may not be kept updated for new Wedge versions and stop working, whereas if it's core and it stopped working it would be a priority bug.
Title: Re: The calendar
Post by: Nao on October 4th, 2011, 06:15 PM
If it's still core it doesn't guarantee it'll work better. We may simply not test it...
Title: Re: The calendar
Post by: Arantor on October 4th, 2011, 07:24 PM
The plugin architecture is designed to support plugin dependencies, though its implementation is rather incomplete. It isn't done by id, however, it's done by hook presence; if a plugin demands one or more hooks, they don't have to be all core hooks - and it's designed so that another plugin can indicate the hooks it provides.

Being core doesn't guarantee it will be well supported, it just guarantees that you'll get it with the core.

There is a distinct part of me that feels putting it into a plugin means support gets better - because the code is localised, we can narrow down changes better.

Plus the whole point of the plugin system is that, frankly, it's supposed to resist changes in Wedge-core and be more resilient as time goes on.

Lastly, the name being <wedge:calendar>, I'm good either way, though I tend to reflect its proper case. A plugin's id is really just an internal identifier, it isn't used for anything other than internal coherence and loading.[1][2]
Posted: October 4th, 2011, 06:55 PM

There is a secondary benefit for doing this: we get the ability to offer a bundle, where users who want the calendar can download it as part of the package if they so choose, with it fairly easy to enable (just a click)
 1. If a plugin wants to load its own template, source, language files etc., it has to supply its id.
 2. I suspect in time I'll extend that to also deal with duplicate detection but I don't know yet.
Title: Re: The calendar
Post by: Nao on October 4th, 2011, 09:03 PM
You seem to have an answer to everything when it comes to plugins. That's refreshing :)
Title: Re: The calendar
Post by: Arantor on October 4th, 2011, 09:14 PM
I deliberately tried to accommodate not only current but future ones, and also to accommodate the crazy sort of things I always wished I could do in SMF.

Plugins that have dependencies was something I always wanted to support after I did it in SimpleDesk, and it makes sense to provide the general facility of plugins being able to indicate their needs and own skills - because it's the only way that I could come up with of automating the dependency management.
Title: Re: The calendar
Post by: Arantor on October 5th, 2011, 12:52 AM
Getting back on topic, I'm definitely getting the feeling about it being plugin, but the more I think about the other stuff, the more I think I wouldn't make them plugins of a plugin, but just enhance the plugin itself if that makes sense.

Doing a search for 'calendar' on the core reveals a lot of hits but they're pretty much all the ones I can actually think of that are relevant to the calendar itself anyway; it's pretty heavily integrated in some bits, but not so heavily integrated that it can't be unbundled that quickly.

I may have to investigate this tomorrow if I get time, I have other things to do like working some more on handling file permissions in the plugin manager as well...

/mealso magically makes the topic public to gather any more feedback, but it's pretty clear where the direction lies.
Title: Re: The calendar
Post by: PantsManUK on October 5th, 2011, 12:54 PM
We use the calendar, but I see the benefits of it shifting out of core, so consider that a +1 for becoming a plugin.
Title: Re: The calendar
Post by: Arantor on October 6th, 2011, 01:38 PM
Anyone else want to add anything before I break out my big wire-cutters?
Title: Re: The calendar
Post by: toolbox on October 6th, 2011, 02:43 PM
Our club would be lost without the calendar system.
Title: Re: The calendar
Post by: Dismal Shadow on October 6th, 2011, 02:45 PM
Quote from toolbox on October 6th, 2011, 02:43 PM
Our club would be lost without the calendar system.
It would still be a official Wedge plugin.
Title: Re: The calendar
Post by: spoogs on October 6th, 2011, 02:56 PM
As much as I make use of the calendar I wouldn't be bothered either way. Having it in the core just means it's already right there in the software, as a plugin just means a few extra clicks to get my hands on it... as long as it works I'm happy :)
Title: Re: The calendar
Post by: Arantor on October 6th, 2011, 03:18 PM
Quote from toolbox on October 6th, 2011, 02:43 PM
Our club would be lost without the calendar system.
Removing it and making it disappear was never at any time part of the proposition. Please re-read the first post in its entirety, because as I said it would be converted into a plugin.[1] It would be available with all the features you currently have, probably get more as well, it would also make us resolve current weaknesses in the plugin system as it would force us to restructure things that haven't yet been overhauled.

Also please note the dearth of topics about our plugin manager. It generally doesn't need file edits; and nothing about the calendar makes me think it would either - which means it's a one click operation to enable - in fact putting aside the actual act of getting the plugin onto the installation, you wouldn't even notice much of a difference - it's not like you get the old install screen or anything.[2]
 1. I appreciate that it is important to you. I'm just annoyed that you appear to have replied without actually taking into account the actual meaning of my post and this conversation in general, and frankly, an uninformed opinion on a debate like this is actually worse than no opinion at all.
 2. This is the point where reading up about the plugin manager would be a good idea. I have posted several screenshots and have discussed at great length how it avoids most of the pitfalls of SMF's package manager, by generally not requiring edits while still extending the system.
Title: Re: The calendar
Post by: godboko71 on October 6th, 2011, 05:14 PM
Another plus if after 1.x ships, it is in an open[1] repo it might garner other maintainers interest. While that could happen while its still in core as a plug in it might be a good testing/proofing groun for future developers of the project.[2]

Anyway that is my +1 to the idea, I think its a great short term and long term exercise for plug-ins and the project as a whole. Hell it could lead[3] a more module system as a whole down the road.
 1. Open as in people can ask for access maybe even make branches to be merged back and all that fun stuff
 2. Who Join you
 3. loooong term
Title: Re: The calendar
Post by: Arantor on October 6th, 2011, 05:17 PM
Why does it have to be an open repo for other people to contribute? All it needs is *active* maintainers and people contributing - the mechanics of it do not require it to be open. In SMF's case, I was contributing bug fixes 8-9 months before they were taken into the core, for example - and their repo isn't open (nor was it at the time), but it didn't prevent me contributing. The blockage was not a lack of openness, but a lack of active maintainers looking at supplied patches and implementing them or rejecting them.

I also doubt that we'll add too many core developers to the project.
Title: Re: The calendar
Post by: godboko71 on October 6th, 2011, 05:29 PM
Why would it be so bad if people could pull from a repo instead of having to download the source :/ Repo or not the point is the same. I know its a sore subject however I am not one of "them" so I wasn't trying to open any wounds.
Title: Re: The calendar
Post by: Arantor on October 6th, 2011, 05:49 PM
You're asking me why it would be so bad to have an open repo - tell me then, why would it be so good if people could pull from a repo instead of having to download the source? Having a milestone release means waypoints for support, for version control etc.

People using SVN versions, except under limited cases, invariably makes the problem so much worse from any real practical perspective, at least in my experience.
Title: Re: The calendar
Post by: godboko71 on October 7th, 2011, 12:40 AM
Quote from Arantor on October 6th, 2011, 05:49 PM
You're asking me why it would be so bad to have an open repo - tell me then, why would it be so good if people could pull from a repo instead of having to download the source? Having a milestone release means waypoints for support, for version control etc.

People using SVN versions, except under limited cases, invariably makes the problem so much worse from any real practical perspective, at least in my experience.
Once you have a stable release people should use that branch, all other modifications (besides maybe minor bug fixes) should go into there own branches only to be merged at final release.

Sure people can post patches/fixes/whatever to your tracker and some will, however for even the slightly dedicated it would be better to have them post to branches that you can review and merge back if you accept the fix. I know in Git or Monotone its very simple to grant different levels of permissions ect and to merge back and forth.
Title: Re: The calendar
Post by: Arantor on October 7th, 2011, 01:00 AM
Quote
Once you have a stable release people should use that branch
Sadly impractical. It would force never backporting fixes to stable branches, amongst other things, because otherwise you'll have some people using 'the stable branch', and some people using 'the stable branch plus some fixes', and it doesn't solve anything, you actually risk fragmenting things worse.

At least with milestone releases, you can locate issues by version. (It's hard enough to get people to actually say what version they have. Very often people can't even get that right. I shudder to imagine them trying to post by revision; at least SVN has revision numbers - Github doesn't last I saw.)
Quote
it would be better to have them post to branches that you can review and merge back if you accept the fix.
Aside from the small fact that trying to merge the disparate branches would be an absolute nightmare. SMF from whence we came, has a very complex nature of inter-dependence. You can't change one thing without having it spread out throughout. Invariably a bug fix requires changes in more than one place, making it rather difficult to actually do this, especially while new things are being coded around it.

If the code were more modular, perhaps it would be feasible, but certainly not the way it is right now.

Thing is, you haven't convinced me why it would be good to open up the repo, you've just told me how I'd use the result, not why it would be good for me, or for Wedge for that matter. I'm happy to review bug fixes and so on, but I'll be absolutely damned if I accept patches in a manner consistent with Github, where someone creates what amounts to a fork branch, commits their changes and magically expects me to commit it. It promotes the expectation that work will be accepted, even when it really won't.

The number of commits accepted from other people thus far is still in single digits. I do not expect that to change as a trend, because we are very protective of our work thus far, and the culture engendered by Github et al, whereby changes are committed into a repo that makes it 'trivial' to incorporate change is actually in my mind a very bad idea. It makes people complacent about including changes, rather than reviewing and putting in the effort to include it.

You see, in all my experience of development, the actually successful projects survive and thrive because they have a specific culture. They have a culture that is a fusion of a meritocracy and a benevolent dictatorship. In other words, people at the top that make the decisions, and people tend to have their opinion listened to more thoroughly if they've proven that they aren't wasting time/effort. If someone consistently posts poor code, I'm not exactly going to be enthusiastic about accepting their bug fixes, now, am I? Yet, social coding explicitly encourages contribution, but it doesn't encourage *good* contribution.

Putting it in the forum is actually a much better barometer for the quality of something in my experience.

Also, see http://wedge.org/pub/off/6923/plugin-development/ which in hindsight is probably a better place for this discussion because we're now so far off topic from what I hoped to discuss...

I don't think it really matters, there's been enough people that have misunderstood the point of what I'm getting at here judging by some of the responses here, not to mention some of the private responses I've had, that I'm actually inclined to leave it in despite my gut instinct.[1]
 1. I've been wrong before about bundling/unbundling features. It makes me wary to consider it much these days.
Title: Re: The calendar
Post by: dorje on October 7th, 2011, 03:43 PM
Not sure if i may post here but...

I just wanted to share with you my "solution" for calendar (or better, for event management). I've disabled the calendar in SMF because in fact it slows my forum (quite sensible differences). But I still need a way to let users insert their events.

So, I've setted up a hidden board (I've created a public child board on a private board, so the index doesn't shwo that board), and a user can insert a topic only by using the custom form (I use a smf mod to do that). So the board has a lot of new topics and the first post is always formatted as you can see here:

http://forum.artistimarziali.org/index.php?topic=9474.0

then, there is a cron job (it runs every hour) that reads all first posts in that board and creates some text files:

The first file is used by a home script that reads all events and shows them through that interface:
http://home.artistimarziali.org/?page=eventi

The second file is used by another cron job (that runs every day), to remove old topics.

The rest of files are read by the board template. If you load, for example, the board 33:
http://forum.artistimarziali.org/index.php?board=33.0
the template includes the file 33.html, and shows it at the top of the board list, with the upcoming events.

I know, the system is not the best design but... It's very fast. And I only use a particular board, I've not implemented other tables. :)
Title: Re: The calendar
Post by: Arantor on October 10th, 2011, 10:32 AM
It's fast because it's essentially pre-cached. Most of the reason the calendar is slow is because it's not cached and is thus queried every page.

That, and the fact it does other stuff as well in a variety of ways...


Anyway, that's not really why I'm posting. Today's question regarding the calendar is regarding birthdays. I'd typically want to set up birthdays separately to the calendar, so I'm thinking I'd rather separate them out entirely, which means a new question as to plugins.

Specifically, let's assume the calendar is going to be a plugin. Should the whole support for birthdays be made a plugin too? (Note: even if I did pull birthdays support into a plugin, I wouldn't remove age/DOB from the forum, because it has other uses that are core, like COPPA type support)
Title: Re: The calendar
Post by: dorje on October 10th, 2011, 10:45 AM
I think that birthday support has to be plugin too, maybe a part of the calendar plugin (but available as option).

The only important thing, imho, is that the DOB field has to be part of the default forum profile fieldset. :)
Title: Re: The calendar
Post by: Arantor on October 10th, 2011, 10:47 AM
Quote
The only important thing, imho, is that the DOB field has to be part of the default forum profile fieldset.
Yup, as stated I had no intention of removing that.
Quote
I think that birthday support has to be plugin too, maybe a part of the calendar plugin (but available as option).
Yes, that's... um... exactly what I'm trying to get at. There's three routes I can take.

* Make birthdays core and calendar a plugin.
* Make birthdays part of the calendar plugin.
* Make birthdays its own plugin.

I'm trying to gauge which is the best route.
Title: Re: The calendar
Post by: PantsManUK on October 10th, 2011, 10:58 AM
re: Birthdays. If your going modular with calendar, I say make birthdays core, but have it send birthdays to the calendar if you've got calendar installed and enabled.
Title: Re: The calendar
Post by: Arantor on October 10th, 2011, 11:01 AM
Quote from PantsManUK on October 10th, 2011, 10:58 AM
re: Birthdays. If your going modular with calendar, I say make birthdays core, but have it send birthdays to the calendar if you've got calendar installed and enabled.
Isn't that the opposite of modularisation? :P
Title: Re: The calendar
Post by: PantsManUK on October 10th, 2011, 11:07 AM
Well, yes, but... I also consider the birthdays code to be a must have (saves me having to post in our birthdays thread :))
Title: Re: The calendar
Post by: Arantor on October 10th, 2011, 11:11 AM
Ah, see, I consider it less of a must-have. But at the same time I'd bring all its functionality together instead of it being disparate as it is now. It would also force me to make sure there is a piece of functionality in the plugin manager that I'd conceived of but not yet implemented.

I'd also likely integrate the other things that are desirable (like the birthday post mod JBlaze and I did).

Thing is, I'd personally rather have birthdays as a plugin on its own rather than being tied explicitly to the calendar; I don't want it on every forum that I run, but where I do, I want it without the calendar - though that is just me.
Title: Re: The calendar
Post by: Arantor on October 10th, 2011, 01:31 PM
OK, I wrote the extra piece of functionality I alluded to in the previous post, now there's no reason why I have to (or not have to) do this :)
Title: Re: The calendar
Post by: spoogs on October 10th, 2011, 01:45 PM
Quote from Arantor on October 10th, 2011, 10:47 AM
* Make birthdays its own plugin.
That^
Title: Re: The calendar
Post by: PantsManUK on October 10th, 2011, 02:21 PM
Quote from spoogs on October 10th, 2011, 01:45 PM
Quote from Arantor on October 10th, 2011, 10:47 AM
* Make birthdays its own plugin.
That^
And following your further explanation, have a +1 from me also; both (all three?) items as plugins. I still think it could hook the calendar if enabled, but all as plugins is where it's at.
Title: Re: The calendar
Post by: Arantor on October 10th, 2011, 02:27 PM
Quote
both (all three?) items as plugins
There's only two plugins being discussed: birthdays and calendar. And yes, birthdays could hook into the calendar; this is precisely what I added to the plugin manager this morning: the ability to define a hook that isn't currently available but won't make it die. So the birthday support has some core requirements (hooking into admin, info centre, etc) and additionally the optional requirement of calendar, so if the calendar is present, use that too.

Since I was going to make the calendar a plugin anyway, it follows that birthdays need changing because right now birthdays are part of (though not really dependent on) the calendar.

Just curious to hear a few more voices on the subject before I do anything.

(Also note: any plugins I build out of the original core, they'll go into my standard repo along with the other plugins I have, which means anyone who has SVN access currently will also have access to those.)
Title: Re: The calendar
Post by: Arantor on October 10th, 2011, 05:11 PM
Please vote: http://wedge.org/pub/feats/6944/birthday-calendar-plugin-core/
Title: Re: The calendar
Post by: MultiformeIngegno on May 1st, 2012, 03:13 AM
Look at this :)
Should I block Googlebot from crawling a dynamically generated calendar?(http://www.youtube.com/watch?v=bAIsnr0dIgo#ws)
Title: Re: The calendar
Post by: Arantor on May 1st, 2012, 03:43 AM
There are reasons SMF has a limit on how far you can create events and thus how far you can go into the past and future ;)

Personally, I'd just flag the entire calendar as noindex,nofollow and be done with it since doing a robots.txt file is... interesting and unreliable when not using pretty URLs.
Title: Re: The calendar
Post by: MultiformeIngegno on May 1st, 2012, 09:49 AM
Right! :)
Title: Re: The calendar
Post by: Nao on May 1st, 2012, 12:46 PM
+1.
Title: Re: The calendar
Post by: Dim on October 27th, 2012, 07:00 PM
Quote from Arantor on October 10th, 2011, 11:11 AM
Thing is, I'd personally rather have birthdays as a plugin on its own rather than being tied explicitly to the calendar; I don't want it on every forum that I run, but where I do, I want it without the calendar - though that is just me.
tend to agree. I would think that very few forums require a birthdays option, whereas a large number will use the standard calendar feature.

For me, the calendar is one of the key components. Run a cycling forum and a large proportion of our threads are for races that go on during the year, so one of our lead portal blocks is a list of upcoming races so users can quickly get to that particular race thread. Think we create several hundred calendar events a year, but by the same token we only use the very basic functionality of it. No private events, or group events etc.
Title: Re: The calendar
Post by: Arantor on October 27th, 2012, 07:36 PM
Actually I disagree with you, it's actually more likely to be the other way around based on the time I spent doing SMF support.

The calendar is a plugin, it currently does not work properly.
Title: Re: The calendar
Post by: Dim on October 27th, 2012, 08:20 PM
Quote from Arantor on October 27th, 2012, 07:36 PM
Actually I disagree with you, it's actually more likely to be the other way around based on the time I spent doing SMF support.

The calendar is a plugin, it currently does not work properly.
saw it was a plugin definately the right move. Surprised that many people care about birthdays, I feel overrun with birthday notifications. Everytime i look at my phone either facebook, google or something else is reminding me of birthdays, failing that its the wife reminding me, or the month texting me to send the grandparents card :S of course that is totally useless as a development comment.