ohla-devel — OHLA developers list. Used to discuss ongoing development of OHLA.

[ohla-devel] [ ohla-Bugs-1535567 ] no rmic in build.xml

[SourceForge.net <no...@so...>]

Bugs item #1535567, was opened at 2006-08-07 00:04
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=731457&aid=1535567&group_id=134950

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mathias Vormelcher (mvormelch)
Assigned to: Nobody/Anonymous (nobody)
Summary: no rmic in build.xml

Initial Comment:
since ohla v0.2 no rmi compiler is used to generate the
stub and tie classes for ohla.jar

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=731457&aid=1535567&group_id=134950

[ohla-devel] ongoing work

[Newcomb, Michael-P. <Mic...@gd...>]

Just to update everyone, I'm in the process of
refactoring/rearchitecting the transport architecture to support group
communication via JGroups (www.jgroups.org). Something should be ready
within the next few weeks.

Thanks,
Michael

[ohla-devel] OHLA 0.2 released

[Newcomb, Michael-P. <Mic...@gd...>]

This release includes initial HLA 1.3 support. IEEE 1516 and HLA 1.3
clients can communicate on the same federation.

Testsuite was moved from JUnit to TestNG.

Some refactoring was done to enable HLA 1.3 support.

Thanks,
Michael

[Ohla-devel] [ ohla-Bugs-1460933 ] ObjectInstanceNameNotReserved exception

[SourceForge.net <no...@so...>]

Bugs item #1460933, was opened at 2006-03-29 15:20
Message generated for change (Settings changed) made by mnewcomb
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=731457&aid=1460933&group_id=134950

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: v0.1.3
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Mathias Vormelcher (mvormelch)
Assigned to: Michael Newcomb (mnewcomb)
Summary: ObjectInstanceNameNotReserved exception

Initial Comment:
Object Management

Federation.java: registerObjectInstance()

I am not sure if the implementation is a little bit
inexact in the last else-statement:

if (name == null || name.length() == 0)
{
        name = "HLA-" + objectInstanceHandle;
}
else if (retiredObjectNames.contains(name))
{
        throw new ObjectInstanceNameInUse(name + " (is
retired)");
}
else if
(!federateHandle.equals(reservedObjectNames.get(name)))
{
throw new ObjectInstanceNameNotReserved(name);
}

If you try to register an object under a name which has
been reserved already (but with a different federate
handle) then two different federate handles are
compared in the last else-statement. Finally an
ObjectInstanceNameNotReserved exception is thrown. But
i expected to get at least an ObjectInstanceNameInUse
exception. The corresponding test code would be the
following:

...
reserveObjectInstanceName("foo");
registerObjectInstance(handle1, "foo");
registerObjectInstance(handle2, "foo");
...
-> ObjectInstanceNameNotReserved exception

If you try to register an object under a name which has
not been reserved already then
'reservedObjectNames.get(name)' returns null and
finally the ObjectInstanceNameNotReserved exception is
thrown by accident:

...
registerObjectInstance(handle, "foo2");
...
-> ObjectInstanceNameNotReserved exception

So to catch this i think the last else-statement needs
to be split again in two further else-statements. One
needs to check if the name was already reserved and the
other one needs to check if the name is already in use
with another federate handle.

----------------------------------------------------------------------

Comment By: Michael Newcomb (mnewcomb)
Date: 2006-04-04 12:09

Message:
Logged In: YES 
user_id=382427

Fixed in 0.1.3.

Code now checks to see if there is an object already 
*registered* under that name and throws an 
ObjectInstanceNameInUse exception.

It then checks to see if the name is reserved. If it is 
not reserved by anyone, it throws an 
ObjectInstanceNameNotReserved exception. If it is reserved 
by another federate, it throws a ObjectInstanceNameInUse 
exception detailing that the name is already reserved by 
another federate.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=731457&aid=1460933&group_id=134950

[Ohla-devel] [ ohla-Bugs-1460933 ] ObjectInstanceNameNotReserved exception

[SourceForge.net <no...@so...>]

Bugs item #1460933, was opened at 2006-03-29 15:20
Message generated for change (Comment added) made by mnewcomb
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=731457&aid=1460933&group_id=134950

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
>Group: v0.1.3
Status: Open
>Resolution: Fixed
Priority: 5
Submitted By: Mathias Vormelcher (mvormelch)
>Assigned to: Michael Newcomb (mnewcomb)
Summary: ObjectInstanceNameNotReserved exception

Initial Comment:
Object Management

Federation.java: registerObjectInstance()

I am not sure if the implementation is a little bit
inexact in the last else-statement:

if (name == null || name.length() == 0)
{
        name = "HLA-" + objectInstanceHandle;
}
else if (retiredObjectNames.contains(name))
{
        throw new ObjectInstanceNameInUse(name + " (is
retired)");
}
else if
(!federateHandle.equals(reservedObjectNames.get(name)))
{
throw new ObjectInstanceNameNotReserved(name);
}

If you try to register an object under a name which has
been reserved already (but with a different federate
handle) then two different federate handles are
compared in the last else-statement. Finally an
ObjectInstanceNameNotReserved exception is thrown. But
i expected to get at least an ObjectInstanceNameInUse
exception. The corresponding test code would be the
following:

...
reserveObjectInstanceName("foo");
registerObjectInstance(handle1, "foo");
registerObjectInstance(handle2, "foo");
...
-> ObjectInstanceNameNotReserved exception

If you try to register an object under a name which has
not been reserved already then
'reservedObjectNames.get(name)' returns null and
finally the ObjectInstanceNameNotReserved exception is
thrown by accident:

...
registerObjectInstance(handle, "foo2");
...
-> ObjectInstanceNameNotReserved exception

So to catch this i think the last else-statement needs
to be split again in two further else-statements. One
needs to check if the name was already reserved and the
other one needs to check if the name is already in use
with another federate handle.

----------------------------------------------------------------------

>Comment By: Michael Newcomb (mnewcomb)
Date: 2006-04-04 12:09

Message:
Logged In: YES 
user_id=382427

Fixed in 0.1.3.

Code now checks to see if there is an object already 
*registered* under that name and throws an 
ObjectInstanceNameInUse exception.

It then checks to see if the name is reserved. If it is 
not reserved by anyone, it throws an 
ObjectInstanceNameNotReserved exception. If it is reserved 
by another federate, it throws a ObjectInstanceNameInUse 
exception detailing that the name is already reserved by 
another federate.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=731457&aid=1460933&group_id=134950

[Ohla-devel] [ ohla-Bugs-1425591 ] Destroying federation removes federation even if it fails

[SourceForge.net <no...@so...>]

Bugs item #1425591, was opened at 2006-02-06 15:49
Message generated for change (Settings changed) made by mnewcomb
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=731457&aid=1425591&group_id=134950

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: v0.1.2
Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Michael Newcomb (mnewcomb)
Assigned to: Michael Newcomb (mnewcomb)
Summary: Destroying federation removes federation even if it fails

Initial Comment:
If a federation is destroyed, it is removed even if 
there are federates still joined. The federation can 
no longer be looked up even though it still exists.

Submitted by: Mathias Vormelcher


----------------------------------------------------------------------

Comment By: Michael Newcomb (mnewcomb)
Date: 2006-02-07 09:14

Message:
Logged In: YES 
user_id=382427

Fixed in 0.1.2.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=731457&aid=1425591&group_id=134950

[Ohla-devel] [ ohla-Bugs-1459183 ] Reserving an Object Instance Name always succeeds

[SourceForge.net <no...@so...>]

Bugs item #1459183, was opened at 2006-03-27 05:00
Message generated for change (Settings changed) made by mnewcomb
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=731457&aid=1459183&group_id=134950

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: v0.1.3
Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Michael Newcomb (mnewcomb)
Summary: Reserving an Object Instance Name always succeeds

Initial Comment:
Reserving an Object Instance Name succeeds even if it 
already exists.

Imagine a test programm setting up a Federation and so 
on with these lines of code:

...
RTIambassador rtiAmbassador = new OHLARTIambassador();
...
rtiAmbassador.reserveObjectInstanceName("Dummy");
rtiAmbassador.reserveObjectInstanceName("Dummy");
...

Running such a programm ends up with two callbacks:
objectInstanceNameReservationSucceeded()

The reason is in net.sf.ohla.rti.Federate.java in 
reserveObjectInstanceName(String name):
the (boolean) variable 'reserved' is never false, so a 
ObjectInstanceNameReservationSucceeded() is always 
thrown.

The reason for that is in 
net.sf.ohla.rti.Federation.java in 
reserveObjectInstanceName(FederateHandle 
federateHandle, String name): the method never returns 
false even if the hashmap 'reservedObjectNames' 
contains already the name.


----------------------------------------------------------------------

Comment By: Michael Newcomb (mnewcomb)
Date: 2006-04-04 10:17

Message:
Logged In: YES 
user_id=382427

Fixed in 0.1.3.

----------------------------------------------------------------------

Comment By: Michael Newcomb (mnewcomb)
Date: 2006-03-27 09:11

Message:
Logged In: YES 
user_id=382427

Excellent catch.

I've adjusted the code to the following.

FederateHandle reservingFederateHandle =
  reservedObjectNames.put(name, federateHandle);
if (reservingFederateHandle != null)
{
  // put it back
  //
  reservedObjectNames.put(name, reservingFederateHandle);
}
return reservingFederateHandle == null;


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2006-03-27 06:09

Message:
Logged In: NO 

submitted by Mathias

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=731457&aid=1459183&group_id=134950

[Ohla-devel] [ ohla-Bugs-1423449 ] Interactions not being delivered to earlier federates

[SourceForge.net <no...@so...>]

Bugs item #1423449, was opened at 2006-02-03 10:30
Message generated for change (Settings changed) made by mnewcomb
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=731457&aid=1423449&group_id=134950

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
>Group: v0.1.1
Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Michael Newcomb (mnewcomb)
Assigned to: Michael Newcomb (mnewcomb)
Summary: Interactions not being delivered to earlier federates

Initial Comment:
As federates join the federation, interactions sent 
by newer federates are never seen by previous 
federates.

Submitted by: Mathias Vormelcher


----------------------------------------------------------------------

Comment By: Michael Newcomb (mnewcomb)
Date: 2006-02-03 10:32

Message:
Logged In: YES 
user_id=382427

Problem was that as new federates came into the 
federation, previous federates failed to update their 
subscription interests with the new federate. Therefore, 
when the newer federate sent out an interaction, the local 
subscriptions for the older federates were empty, because 
the older federates never notified the newer federate what 
they were subscribed to.

This fix will be available in the 0.1.1 preview release.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=731457&aid=1423449&group_id=134950

[Ohla-devel] [ ohla-Bugs-1425591 ] Destroying federation removes federation even if it fails

[SourceForge.net <no...@so...>]

Bugs item #1425591, was opened at 2006-02-06 15:49
Message generated for change (Settings changed) made by mnewcomb
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=731457&aid=1425591&group_id=134950

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
>Group: v0.1.2
Status: Closed
Resolution: None
Priority: 5
Submitted By: Michael Newcomb (mnewcomb)
Assigned to: Michael Newcomb (mnewcomb)
Summary: Destroying federation removes federation even if it fails

Initial Comment:
If a federation is destroyed, it is removed even if 
there are federates still joined. The federation can 
no longer be looked up even though it still exists.

Submitted by: Mathias Vormelcher


----------------------------------------------------------------------

Comment By: Michael Newcomb (mnewcomb)
Date: 2006-02-07 09:14

Message:
Logged In: YES 
user_id=382427

Fixed in 0.1.2.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=731457&aid=1425591&group_id=134950

[Ohla-devel] [ ohla-Bugs-1459183 ] Reserving an Object Instance Name always succeeds

[SourceForge.net <no...@so...>]

Bugs item #1459183, was opened at 2006-03-27 05:00
Message generated for change (Settings changed) made by mnewcomb
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=731457&aid=1459183&group_id=134950

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
>Group: v0.1.3
Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Michael Newcomb (mnewcomb)
Summary: Reserving an Object Instance Name always succeeds

Initial Comment:
Reserving an Object Instance Name succeeds even if it 
already exists.

Imagine a test programm setting up a Federation and so 
on with these lines of code:

...
RTIambassador rtiAmbassador = new OHLARTIambassador();
...
rtiAmbassador.reserveObjectInstanceName("Dummy");
rtiAmbassador.reserveObjectInstanceName("Dummy");
...

Running such a programm ends up with two callbacks:
objectInstanceNameReservationSucceeded()

The reason is in net.sf.ohla.rti.Federate.java in 
reserveObjectInstanceName(String name):
the (boolean) variable 'reserved' is never false, so a 
ObjectInstanceNameReservationSucceeded() is always 
thrown.

The reason for that is in 
net.sf.ohla.rti.Federation.java in 
reserveObjectInstanceName(FederateHandle 
federateHandle, String name): the method never returns 
false even if the hashmap 'reservedObjectNames' 
contains already the name.


----------------------------------------------------------------------

Comment By: Michael Newcomb (mnewcomb)
Date: 2006-04-04 10:17

Message:
Logged In: YES 
user_id=382427

Fixed in 0.1.3.

----------------------------------------------------------------------

Comment By: Michael Newcomb (mnewcomb)
Date: 2006-03-27 09:11

Message:
Logged In: YES 
user_id=382427

Excellent catch.

I've adjusted the code to the following.

FederateHandle reservingFederateHandle =
  reservedObjectNames.put(name, federateHandle);
if (reservingFederateHandle != null)
{
  // put it back
  //
  reservedObjectNames.put(name, reservingFederateHandle);
}
return reservingFederateHandle == null;


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2006-03-27 06:09

Message:
Logged In: NO 

submitted by Mathias

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=731457&aid=1459183&group_id=134950

RE: [Ohla-devel] Object Management

[Newcomb, Michael-P. <Mic...@gd...>]

Mathias,

It isn't spelled out specifically in the post conditions (which it
should have), but if you look at the wording of the section you will see
it.

1516.1-2000.pdf, page 84 (92 of 475)

6.10 Delete Object Instance

The Delete Object Instance service shall inform the federation that an
object instance with the specified designator, which has the
HLAprivilegeToDeleteObject instance attribute that is owned by the
joined federate, is to be removed from the federation execution. Once
the object instance is removed from the federation execution, the
designator and name shall not be reused and all joined federates that
owned attributes of the object instance shall no longer own those
attributes. The RTI shall use the Remove Object Instance service to
inform all other joined federates which know the object instance that
the object instance has been deleted. The invoking joined federate shall
own the HLAprivilegeToDeleteObject attribute of the specified object
instance.

In the 2nd sentence: "... the designator and name shall not be reused
...".

Thanks,
Michael

> -----Original Message-----
> From: ohl...@li...=20
> [mailto:ohl...@li...] On Behalf Of=20
> Mathias Vormelcher
> Sent: Wednesday, March 29, 2006 4:08 PM
> To: ohl...@li...
> Subject: [Ohla-devel] Object Management
>=20
> hi,
> i have a question. In Federation.java OpenHLA manages a list=20
> of names that have been ever in use in combination with an=20
> object instance named 'retiredObjectNames'. Maybe it is=20
> because my native language is not english (maybe i don't=20
> understand it correct) but i would have interpreted the IEEE=20
> 1516 specification not like this. Especially for the method=20
> 'deleteObjectInstance()' it is not clearly said that the name=20
> shall never be reused again (for example in the post-conditions).
> Perhaps i am false? For what exact reason the=20
> 'retiredObjectNames'-list is necessary?
>=20
> greetings,
> Mathias
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking=20
> scripting language that extends applications into web and=20
> mobile media. Attend the live webcast and join the prime=20
> developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D110944&bid=3D241720&
> dat=3D121642
> _______________________________________________
> Ohla-devel mailing list
> Ohl...@li...
> https://lists.sourceforge.net/lists/listinfo/ohla-devel
>=20

[Ohla-devel] Object Management

[Mathias V. <mat...@gm...>]

hi,
i have a question. In Federation.java OpenHLA manages a list of names 
that have been ever in use in combination with an object instance named 
'retiredObjectNames'. Maybe it is because my native language is not 
english (maybe i don't understand it correct) but i would have 
interpreted the IEEE 1516 specification not like this. Especially for 
the method 'deleteObjectInstance()' it is not clearly said that the name 
shall never be reused again (for example in the post-conditions).
Perhaps i am false? For what exact reason the 'retiredObjectNames'-list 
is necessary?

greetings,
Mathias

[Ohla-devel] DoD interpretations

[Newcomb, Michael-P. <Mic...@gd...>]

https://www.dmso.mil/public/resources/documents?tree-e=3DeJyLVneEguSiclt1=
H
QUEv9QElW/kisJPccq3VY8FABEYEDA#AAAAAAAAdBo=3D

I think I'm going to implement the DoD interpretations for both 1.3 and
1516 versions of HLA. Especially since most applications of HLA are in
the defense industry.

Any objections?

Thanks,
Michael

RE: [Ohla-devel] time management

[Newcomb, Michael-P. <Mic...@gd...>]

> -----Original Message-----
> From: ohl...@li...=20
> [mailto:ohl...@li...] On Behalf Of=20
> Dillman, Brad
> Sent: Tuesday, March 14, 2006 11:06 AM
> To: ohl...@li...
> Subject: [Ohla-devel] time management
>=20
> Hi, my name is Brad Dillman. I work for Defence R&D Canada=20
> Atlantic, and in my spare time (aside from 3 kids, etc.) I'm=20
> working on modifications for OpenHLA to support time=20
> management. So far, I can send TSO messages from 1 time=20
> regulating federate to 1 time constrained federate. It feels=20
> like most of the implementation is done, and debugging and=20
> unit testing are what's left.
>=20
> I haven't made time management into a separate, pluggable=20
> module as I would've liked, because at the time I couldn't=20
> think how to separate out time management from the rest of the RTI.
>=20
> But I think I have a plan now on how to do that.=20
>=20
> I was looking at 2 solutions to the problem of transient=20
> messages: A) use serial numbers on reliable transport=20
> messages, and have a centralized time management algorithm=20
> control messages using those serial numbers, or B) send time=20
> advance information 'in-line' with data over reliable=20
> transport (since TCP guarantees order, you'll get the data=20
> before the time info).=20
>=20
> I chose B) because I thought it would perform better over a=20
> WAN (I've spent a while investigating how time management=20
> behaves over a WAN).
>=20
> But what I now realize (I think) is TSO messages should=20
> always be gated by serial numbers, but leave it up to the=20
> time management algorithm how to manage those serial numbers.=20
> That is, the two approaches could be combined; there's=20
> nothing saying I couldn't send time advance info with serial=20
> numbers over a reliable transport (although you might not need
> it) - the extra serial number data isn't enough to make a big=20
> performance difference even if it isn't used.
>=20
> So, rather than a tight (ugly) coupling between time=20
> management and TSO message queuing, they should be coupled=20
> via serial numbers. That is, a serial number for each=20
> publishing reliable transport (I think).
>=20
> A cleaner interface between the time management code and TSO=20
> queues would be defined in terms of serial numbers. The TSO=20
> queues would offer services to a time management system like=20
> getLastSerialNumber(...) and releaseAllUntil(serialNumber, ...).
>=20
> Should I put my current stuff in archive and begin anew?
>=20
> I think so, I could consider my current version 'an=20
> educational experience', and steal some working bits from it=20
> quite easily. Pluggable time management would be really neat=20
> feature for our research, and some other researchers I've=20
> spoken with agree, though I don't see any non-research demand=20
> for it (or for time management in general).
>=20
> Thanks,
> Brad Dillman, DRDC Atlantic

All I can say is wow...

I'm doing some refactoring right now because the DoD interpretations
have moved all the 1516 interfaces to 'hla.rti1516'.  This will allow
HLA 1.3 support to be much easier and directly integrated to OHLA as a
whole.

As soon as I'm done with this latest package refactoring, I'll release
it. If the structure seems sound, I'll go ahead and check it into
subversion.

Thanks,
Michael

[Ohla-devel] time management

[Dillman, B. <Bra...@dr...>]

Hi, my name is Brad Dillman. I work for Defence R&D Canada Atlantic, and
in my spare time (aside from 3 kids, etc.) I'm working on modifications
for OpenHLA to support time management. So far, I can send TSO messages
from 1 time regulating federate to 1 time constrained federate. It feels
like most of the implementation is done, and debugging and unit testing
are what's left.

I haven't made time management into a separate, pluggable module as I
would've liked, because at the time I couldn't think how to separate out
time management from the rest of the RTI.

But I think I have a plan now on how to do that.=20

I was looking at 2 solutions to the problem of transient messages: A)
use serial numbers on reliable transport messages, and have a
centralized time management algorithm control messages using those
serial numbers, or B) send time advance information 'in-line' with data
over reliable transport (since TCP guarantees order, you'll get the data
before the time info).=20

I chose B) because I thought it would perform better over a WAN (I've
spent a while investigating how time management behaves over a WAN).

But what I now realize (I think) is TSO messages should always be gated
by serial numbers, but leave it up to the time management algorithm how
to manage those serial numbers. That is, the two approaches could be
combined; there's nothing saying I couldn't send time advance info with
serial numbers over a reliable transport (although you might not need
it) - the extra serial number data isn't enough to make a big
performance difference even if it isn't used.

So, rather than a tight (ugly) coupling between time management and TSO
message queuing, they should be coupled via serial numbers. That is, a
serial number for each publishing reliable transport (I think).

A cleaner interface between the time management code and TSO queues
would be defined in terms of serial numbers. The TSO queues would offer
services to a time management system like getLastSerialNumber(...) and
releaseAllUntil(serialNumber, ...).

Should I put my current stuff in archive and begin anew?

I think so, I could consider my current version 'an educational
experience', and steal some working bits from it quite easily. Pluggable
time management would be really neat feature for our research, and some
other researchers I've spoken with agree, though I don't see any
non-research demand for it (or for time management in general).

Thanks,
Brad Dillman, DRDC Atlantic