Re: 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.

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.

[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.

>> 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? 
1a)Are there any of you who are willing to be active developers on core 
functionality? 
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"?  ;-)

2) How is Java.net working out?  Are you moving there completely?
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

>>
>> 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