Re: OScheduler

See inline.
----- Original Message -----
From: "James House" <[email protected]>
To: <[email protected]>
Sent: Monday, January 12, 2004 12:38 AM
Subject: Re: [Opensymphony-developers] OScheduler


>
> Mathias,
>
> [Brief interuption before the real message:   It seems that I'm only
> seeing about 50% of this conversation - - at least I don't get any
> e-mail that came from Mathias himself - I only see his comments in the
> bodies of people's responses to his messages.... does anyone know why
> this would be? I'm subscribed to
> "[email protected]" -- Mathias, if you
> respond, can you please cc me ([email protected]) directly?].
>
> I think (although of course I'm biased) Quartz is fairly light-weight,
> and its more complex features don't have to be used (and can therefore
> be ignored in the configuration) - of course you have to weed though it
> a bit to see what you can ignore ;-).  I've never heard a complaint that
> Quartz is hard to use (in fact, the forums are full of comments about
> how easy it is) - But you are right in saying that it is more complex
> than it needs to be, and the interfaces/classes have become inconsitent
> over time, and in fact some abstractions are being violated due to
> changes in direction.  It's a classic case of learning what the product
> really should be, once you've already got it made, and people start
> using it and asking for changes in the features.

As Hani mentioned, the API (IMO overall, not only JobStore) seems too
verbose. Too many methods to implement.

>
> I think a collaboration would be great.  If nothing else, I'd like to
> see how your ideas can improve my Quartz 2.0 design. :)   I've been
> really focused in the design on accomodating things like clustering,
> CMT, and improved load balancing, and it is likely that too much
> complexity is still touching the upper layers of the API -- additional
> (critical) eyes would be appreciated.   Perhaps your API is already
> perfect, and it should be adopted.  Or perhaps (more likely) meshing the
> two designs together will produce something top-notch.  Of course it is
> also possible that we'll find the goals of the two project are so
> divergent that both should exist - though I'd be surprised to find this
> to be the case.

My API is simpler, but is also less featured. It's based a lot of how
XWork's API is, since a Job resembles to an XWork Action a lot. I think that
meshing them and though collaboration and the community feedback designing
the perfect API is the best approach to take.

>
> [For those unfamiliar with the current state of Quartz:]
> Quartz the project now has a very large and fairly active community
> base.  I am still by far the primary contributor, but there are a couple
> others who commit a few times per month, and there are regularly patches
> and new (small) features submitted.   Best of all, the user forum is
> nearly running itself, thanks to having enough experienced users who are
> willing to help out the noobs.   The last official release of Quartz
> (1.2.3) has nearly 3000 downloads, aside from being contained
> (distributed) within several other open source and commercial
> products.   Quartz 1.3.0 should be release within a few days, and 1.4.0
> in about a month.    Quartz 2.0 was designed a long while back, and
> implementation began, but it's got MANY hours of work to go, since it is
> a serious refactoring.   Both the existing (1.x) design and the 2.0
> design support plugable persistence.  There is currently RAM and
> JDBC-based persistence (a bit of an oxymoron with RAM).  Also there is a
> mechanism to use XML files to auto-populate jobs in the RAM store during
> initialization.
>
> In answer to your questions:
>
> >> 1. OS components are lean and mean, so I'm not sure some of Quartz
> >> features
> >> will 'fit' in, e.g. RMI, how do you see this?
> >
> Patrick already answered this a bit.   Additionally, all of the advanced
> features are "optional use", and don't even have to be configured if you
> aren't using them.  Furthermore, these "advanced" features don't really
> tax the system much.  When Quartz is running with all features enabled,
> it's often hard to measure the load it is causing on the system.  I'm
> usually known (in my day job) as one who tends to err on the side of
> efficiency.
>

Having a lot of features is nice, but the question is 'are all these
features as useful as they are cool'. RMI support might be nice, but if 1%
of the users is actually using it, it would be better to put it in a
quartz-extras subproject.

> >> 2. The package should be com.opensymphony.quartz, objections?
> >
> No objections there.  I'd propose the switch happen with the 2.0 release
>
> >> 3. What are your main motivations for moving to OS now and not before?
> >
> The main thing stopping me before was that my employer (PartNET) was
> giving me some on-the-clock hours to work on Quartz, and it didn't have
> much of a community yet.  Becuase PartNET was "investing" in it, my boss
> was hesitant to give it over to a community, when he was still unsure
> about how he may want to profit from it.  At this point, this isn't an
> issue any more.  All of Quartz's files currently say "Copyright James
> House" in them - and there are no claims to ownership by PartNET.
> Furthermore, I don't get company time to work on it anymore (never did
> get very many hours in the first place), and the 2.0 design was done
> entirely on my own time.
>
> If the OS community is willing to have Quartz, I'll first need to run it
> by a few of the other people over on the Quartz project, who ought to at
> least have a little say about it.  And frankly I've got just a little
> bit of hesitancy still in me myself (perhaps I'm too proud, but it is
> kind of hard to go from something that's nearly 100% yours, to it only
> being 50% or so yours).  However, I'm thinking that this is probably the
> best way to go, as I could really use the additional support (if there
> is some here).  As I said in my previous e-mail, I was planning to
> approach Patrick (and OpenSymphony in general) about this some time soon
> (when I made up my mind definitively), but seeing this mail thread
> spurred me into it.
>
>
> Some things I'd like to know:
>
> 1) Why would OpenSymphony want Quartz?  What does OpenSymphony have to
> offer Quartz?

Quartz is the only decent J2EE scheduler around. Period.

> 1a)Are there any of you who are willing to be active developers on core
> functionality?

I would offcourse be interested.

> 1b)Are there any of you who are willing to be active developers on
> making Quartz work well with (integrate with) other OpenSymphony projects?
> 1c)Are there any of you who are willing to be forum supporters etc.?
> 1d)Are there any of you who are willing to pat me on the back and say
> "good job"?  ;-)

As with any of the other OS projects, the moment that you have design
questions or would like feedback on something, the OS developers are there.
People already discuss a whole lot of topics concerning OS. Check the
archives. In the end, for most of us this is a learning thing. Although many
of us are around for quite a while, most of us are perfectionists looking
for the coolest design, the 'holy grail'. It's addictive.

>
> 2) How is Java.net working out?  Are you moving there completely?

Very good for now. Performance is superb!

> 2a) Where/how do you guys host your site?  (I've got a tomcat server
> that I run the Quartz website and wiki (SnipSnap) on, as well as
> ownership of the domain "quartzscheduler.org" (and ".com"), a
> mail-server, and I happily use JIRA for issue tracking).   -- Thus
> Quartz is primarily using SourceForge for file distribution and the
> forum (though the forum software really bites).  If Quartz is going to
> be an OpenSymphony project, it ought to sit along side the others
> (actually I'm not entirely sure how much the others are all hosted the
> same place, in the same way, etc.) -- I guess my question really is:
> Where will it be expected that Quartz is hosted (mail, forum, CVS,
> documentation, "home page", wiki, etc.)   -- Also, I'm willing to offer
> my server (on a T3 with 40GB available transfer per month) for anything
> that's needed.
>
> james

Mathias

>
> >>
> >> Cheers,
> >> Mathias
> >>
> >> ----- Original Message -----
> >> From: "James House" <[email protected]>
> >> To: <[email protected]>
> >> Sent: Friday, January 09, 2004 9:44 PM
> >> Subject: Re: [Opensymphony-developers] OScheduler
> >>
> >>
> >>>
> >>> Matthias,
> >>>
> >>> James here (primary developer of Quartz).  I don't know if your
> >>> interested or not, but I've had a full new design of Quartz (Quartz
> >>> 2.0)
> >>> getting dusty for several months no, and was getting ready to actually
> >>> dig in and build the thing (The work is about 20% done, and the
> >>> changes
> >>> include: a significantly improved/changed API, usage of Hibernate for
> >>> persistence, over-hauled clustering features, re-thinking of how
> >>> guarantees and prioritization of job firings (and misfirings) occur,
> >>> etc.).   In the past I had been invited to join Quartz under the OS
> >>> umbrella, and had declined, but I was actually planning to write an
> >>> e-mail to Patrick in the next week or so and ask if I'm still welcome,
> >>> and see if anyone wants to help...  I'm also interested in leaving
> >>> SourceForge and moving java.net.
> >>>
> >>> Anyway what are your thoughts on a collaborative effort?
> >>>
> >>> james
> >>>
> >>>
> >>> Hani Suleiman wrote:
> >>>
> >>>> Yep, that's what I was going to propose. xml, ejb, and memory.
> >>>>
> >>>> Mathias Bogaert wrote:
> >>>>
> >>>>> I'm not a big fan of multiple persistence mechanisms (look at the
> >>>>> many
> >>>>> problems with it in OSUser/OSAccess). Hibernate supports all
> >>>>> kinds  of
> >>>>> databases, so no problem there. And offcourse, the API allows to
> >>>>> plug, but
> >>>>> except for perhaps an XML and EJB one, I don't think we should add
> >>>>
> >> more.
> >>
> >>>>>
> >>>>> Mathias
> >>>>>
> >>>>> ----- Original Message -----
> >>>>> From: "Hani Suleiman" <[email protected]>
> >>>>> To: <[email protected]>
> >>>>> Sent: Friday, January 09, 2004 9:17 PM
> >>>>> Subject: Re: [Opensymphony-developers] OScheduler
> >>>>>
> >>>>>
> >>>>>
> >>>>>> Yes! Although the one thing that is glaringly missing from your
> >>>>>> description is support for multiple persistence mechanisms, so any
> >>>>>> objections to adding that in?
> >>>>>>
> >>>>>> Anyway, big +1 from me for having such a component, as long as it
> >>>>>> follows the same principles as all the others (few dependencies,
> >>>>>> optional support for stuff, etc etc).
> >>>>>>
> >>>>>> Mathias Bogaert wrote:
> >>>>>>
> >>>>>>
> >>>>>>> Guys,
> >>>>>>>
> >>>>>>> Over the last month, I've written a scheduler (like Quartz),
> >>>>>>> but  with
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> much
> >>>>>
> >>>>>>> cleaner interfaces, based on java.util.Timer, lot of the same
> >>>>>>> principals
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> as
> >>>>>
> >>>>>>> XWork (Job, JobSupport, JobInvocation, interceptors, etc),
> >>>>>>> using  the
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> cron
> >>>>>
> >>>>>>> parser from OSCache, with Hibernate as backing store for
> >>>>>>> storing  jobs
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> and
> >>>>>
> >>>>>>> job parameters (that are set on a job having setters). Startup
> >>>>>>> through a
> >>>>>>> context listener. The documentation is a work in progress, and
> >>>>>>> it's
> >>>>>>> not
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> very
> >>>>>
> >>>>>>> well tested (almost zero unit tests, I'm not into TDD yet).
> >>>>>>>
> >>>>>>> I've been thinking about releasing it as open source, and I'm
> >>>>>>> wondering
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> if
> >>>>>
> >>>>>>> OpenSymphony would be interested. Offcourse any better name or
> >>>>>>> other
> >>>>>>> suggestions are appreciated.
> >>>>>>>
> >>>>>>> Mathias Bogaert
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> -------------------------------------------------------
> >>>>>>> This SF.net email is sponsored by: Perforce Software.
> >>>>>>> Perforce is the Fast Software Configuration Management System
> >>>>>>
> >> offering
> >>
> >>>>>>> advanced branching capabilities and atomic changes on 50+
> >>>>>>> platforms.
> >>>>>>> Free Eval! http://www.perforce.com/perforce/loadprog.html
> >>>>>>> _______________________________________________
> >>>>>>> Opensymphony-developers mailing list
> >>>>>>> [email protected]
> >>>>>>> https://lists.sourceforge.net/lists/listinfo/opensymphony-
> >>>>>>> developers
> >>>>>>>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Perforce Software.
> Perforce is the Fast Software Configuration Management System offering
> advanced branching capabilities and atomic changes on 50+ platforms.
> Free Eval! http://www.perforce.com/perforce/loadprog.html
> _______________________________________________
> Opensymphony-developers mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/opensymphony-developers
>
>



-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html