Remove Job Scheduler dependency

I think new users will find it difficult to create timed importers then.
Most likely that new users come to Feeds module with "Feeds" keyword, that gives a sense of fetching something over the web, in timed schedulers.
So if we remove the dependency and user module_exists() to display a message saying they need to install Job Scheduler first, isn't that confusing ?

However, it'd be impressive if we overcome this with a rewriting!

It's really confusing that Feeds require Job Scheduler. and true - project page is not stating that.
+1 for the idea to put a note in project page and remove the dependency!
Shorten and Short URL module play nicely like this. Shorten module doesn't require Short URL, but integrates nicely with Short URL if exists.
Lets see what Alex or other maintainers say :)

I have used Feeds several times to handle one-time data migrations, using drush (see #608408: Drush integration for Feeds). The job scheduler was completely unnecessary for my use case and I think removing it as a dependency makes sense. Feeds could show a notice indicating that more functionality will become available if Job Scheduler is enabled, like Views and Advanced Help. So, +1 from me.

+1 it was really annoying that the Jobs Scheduler requirement is not mentioned at all on the project page and I had to find out after seeking to install the module as a requirement for yet another module. Documentation is golden. :)

If this patch is going to go anywhere, it needs to be against 7.x first.
It would be better if we added a method to FeedsImporter that checks if we should schedule, rather than a bunch of module_exists() calls.
Coding standard issues.

Patch does not work on latest dev. Conflicts in FeedsSource.inc

* Rerolled patch against latest 7.x-2.x version on Git
* Some minor fixes

HTH

The 9 failed tests are related to the 'feed_scheduler' tests. Don't know what else I can do. If someone can lend a hand, it will be very appreciated.

I would also be interested in this. I use feeds on a number of sites and all of them are manual imports. It wouldn't be so bad if Job Scheduler had a non-alpha release in the last year. I know that the current alpha is pretty stable (although I'm not really using it, despite it being installed), but people frown on it when I use alphas or dev versions. It seems like it is under active development now, but still no stable releases since May 2012. So you either use a dev version or a very old version, and all for functionality I'm not even using.

Shame this hasn't gained any more traction... Job Scheduler is on the brink of being an abandoned project considering the last update to dev was 2015. Is it worth the maintainers of feeds to assume control of Job Scheduler or simply re-write and incorporate the functions of Job Scheduler? Wouldn't it make more sense to use Rules scheduler for this sort of thing?

Personally, I don't find it worth the effort to remove the dependency, but I can understand the reasons for removing it:

1. Job Scheduler seems to be no longer maintained.
2. The dependency is only useful when using one or more of the following features:
   • Periodic import
   • Expire content (for example: automatically remove content that was imported over a year ago)
   • Until beta3: process in background

There are also reasons to keep the dependency:

1. I think the periodic import feature is one of the core features of the Feeds module. It should be very visible for new users, so at least be available by default.
2. The integration with Job Scheduler is quite tight. Removing it may cause BC breaks. For example, calling schedule() on a FeedsSource instance would either result into errors or do nothing when Job Scheduler isn't available. Other modules are now free to call that method on a FeedsSource object.
3. I think it is quite a lot of work to remove the dependency properly: you have to think about what needs to happen if methods on a FeedsSource instance are called that require the availability of Job Scheduler. In my opinion, the time invested in that doesn't weigh up to the benefits which would be:
   • tiny performance gain: less PHP code to load on each request, one database query less on each cron run.
   • tiny smaller chance of running into a bug or a security issue.

@MegaChriz would it be possible to leverage all of the functionality of Job Scheduler through Rules? I honestly don't know from a logistics standpoint.

@philsward
I haven't used the Rules Scheduler module myself yet, but I suppose it would be possible to achieve the same kind of functionality via that route. This will require at least the following:

• There needs to be a Rules action for running a Feeds importer (patch available in #2446307: Trigger Feed Import Using Rules).
• For each importer a default rule needs to be created.
• When changing the 'Periodic import' setting, the default rule needs to change as well, in order to correctly reflect that setting.
• When a rule belonging to an importer gets overridden, this somehow would need to be visible in the Feeds UI. The 'Periodic import' setting probably needs to be grayed out and a warning message would need to be shown.

I'm not sure though if that is a satisfactory solution to this problem. This solution would just replace the Job Scheduler dependency with a dependency on Rules Scheduler.

@MegaChriz I understand the change to dependencies but considering the lack of development for job scheduler and the on going development of rules, it might make the most sense.

Mainly just throwing the idea out there.

Ideally, feeds should have a scheduled importer sub-module that uses a dependency, that way feeds itself isn't dependent on anything else. If a person needs scheduled imports, that's when they would have to use the dependency in order to enable the feeds scheduler sub module.

At this point, it looks like it's a lot of work to move forward, regardless of how the pie is sliced.

@philsward
I appreciate your idea and I agree that swapping Job Scheduler with Rules Scheduler could be a good idea because the latter is better supported. Having a submodule to provide scheduled import functionality sounds also like a great idea to me, although I'm slightly concerned this would require a BC-break. Modules calling the schedule() method on a FeedsInstance object would now only depend on Feeds (not the submodule). What would the effect of that method be when the submodule isn't enabled? Etc.
I would appreciate any efforts made to fulfill this feature request, although I'm not interested enough in it to work on it myself.

@MegaChriz due to the changes, it sounds like it would almost warrant a version fork, but that would be a lot to maintain...

Totally understand the time constraints and I appreciate you considering the options. I don't have the means to push anything at the moment either, so maybe the discussion will provide others with some ideas if they feel it needs addressed.

Now that #2446307: Trigger Feed Import Using Rules has landed, I am interested in this as well. Will try to put some cycles towards it.