Paging support for IScheduler

Current interfaces to fetch jobs and triggers don’t support paging. But in case if there are many jobs or triggers the methods take some time to return data (see maikebing/SilkierQuartz#57 for example). Also it’s not feasible to use them for HTTP API for the same reason.

IScheduler should be extended to provide methods for fetching paged data.

I created PR #1272 as a draft of how the API should look like. I considered extending existing methods instead of creating overloads but in order to maintain Application Binary Interface compatibility overloads should be used. That’s due to the way how default values for methods are used.

In short my suggestion is to provide additional parameters for methods returning collections:

• long take
• long skip

These parameters map nicely to database queries. And using these parameters it’s possible to implement simple paging. Implementing paging in form of showing page numbers like [1] [2] **3** [4] [5] .. [10] will still be troublesome since that requires to know precise amount of items for the endpoint. I suggest to de-scope it and first implement the simplest paging described above.

[lahma]

TBH I’m not super excited to introduce EF to the mix for data access. It has its merits and can make things easier, but the core library doesn’t currently have any deps to “fat libraries”.

Current data access implementation is quite low-level and even archaic, 1:1 ideology with Java version, and doesn’t require dependencies. Of course good API allows you to switch to EF provider with extra package dependency.

The APi requires some overhaul to support document databases in efficient way anyway.

[lahma]

Ideally I would see a project like SilkierQuartz or other established solution to be integrated into Quartz, allowing original maintainer(s) to improve and main Quartz project to ensure integration works as expected. I think a stable HTTP API is a first step, and has to account for paging.