Re: [Q] Noddy scheduling question

[Ken Cline]

On Tue, 6 Jul 1999, Marcus G. Daniels wrote:

> >>>>> "GP" == Gary Polhill <address@hidden> writes:
> 
> GP> ... Is there something inherently wrong with wanting
> GP> to start something at time 10, say, that will then
> GP> repeat each time slot?
> 
> Not at all -- but understand that the RepeatInterval
> feature fixes a *region* for scheduling that is *tiled*.
> If you go past the tiling boundaries, Swarm complains.
> 
> What I usually do with this sort of thing is dynamic
> scheduling, i.e. every repetitive behavior takes direct
> responsibility for rescheduling itself.  I tend to use
> approach just because I like going straight to particular
> places in the model source code to find out things about
> agents.
> 
> OTOH, what was *intended* is to create a one-shot startup
> schedule that creates and activates a subswarm with a
> schedule that has the RepeatInterval and RelativeTime
> parameters set.  Unfortunately this doesn't work in 1.4.1;
> it will in 2.0.

Do you think it would be useful to have an additional
activity interface, one targeted to creating "semi-repeating"
actions (for lack of a better term)?

I was thinking of something like:
  @protocol ActionSequence <RepeatInterval>
    SETTING
    -setStart: (timeval_t) t; // I'm not sure the set methods
    -setEnd:   (timeval_t) t; // need to be in the protocol?
    USING
    -(timeval_t) getStart; // Absolute time
    -(timeval_t) getEnd;   // Absolute time
  @end
where the default for start would be 0, the default for end
would be `TimebaseMax' and the default for the repeat 
interval would be 1.  (Note: the "set" methods probably
really belong in a sub-protocol, e.g. SimpleActionSequence,
and/or a default implementation.)

There could be an extension of the Schedule protocol that
accepts an "ActionSequence", e.g.
  @protocol ScheduleSequel <Schedule>
    USING
    -during: (id <ActionSequence>) seq createAction: (id <ActionType>) act;
      ...
  @end

I'm not sure that the protocol and method names are the best
choices to convey the purpose of the interfaces and behavior,
respectively, but I think you get the idea.  Does anyone
think this interface would be useful?  Is there a better way
to achieve this functionality? Is the existing way better?

One issue that I can see immediately is that you might not
want repeating schedules to also have "ActionSequences";
that would probably create a mess.  However, that's not
necessarily a problem since the interface provides an
alternative way to create an endlessly repeating action,
right?  Any other issues that you can see?

Comments?  (BTW, I'm not claiming this as a wholly original
idea. In fact, maybe someone has already mentioned something
like this on the list before?)

Ken.


PS: On a somewhat related topic, another schedule extension
that I've been thinking about is a "filtered" schedule.
This is just a schedule that has a hook so you can add an 
"ActionFilter".  That is:
   @protocol FilteredSchedule <Schedule>
     SETTING
     -setActionFilter: (id <ActionFilter>) filter;
     -(id <ActionFilter>) getActionFilter;
   @end
where
   @protocol ActionFilter
     USING
     -(BOOL) accept: (id <ActionType>) action;
   @end

Every action must be "accepted" by the filter before it will
be inserted into the schedule.  This might be useful for
attaching an event logger to a schedule, for example:

   @implementation MyArchiver // conforms to ActionFilter
      ...
   -(BOOL) accept: (id <ActionType>) action {
      if ( [self isTarget: action] )
        [ self logEvent: action ];
      return TRUE;
   }
     ...
   @end

Well anyway, its just an idea...

_________________________________________________________
Ken Cline                             address@hidden
SAIC                                 VOICE (410) 571-0413
Annapolis, MD                          FAX (301) 261-8427





                  ==================================
   Swarm-Support is for discussion of the technical details of the day
   to day usage of Swarm.  For list administration needs (esp.
   [un]subscribing), please send a message to <address@hidden>
   with "help" in the body of the message.