[rt-devel] Linking actions (for 2.0)

['Jesse']

On Mon, Apr 24, 2000 at 11:16:46AM -0400, Rouillard, John wrote:
> 
> Jesse said:
> > On Fri, Apr 14, 2000 at 01:57:20PM +0200, Tobias Brox wrote:
> > > I think we more or less have a concensus about what links should be
> > > available for 2.0, and how they should behave:
> > > 
> > > <BASE> DependsOn <TARGET>
> > > 
> > > ...meaning that TARGET has to be resolved before BASE (really) is
> > > resolved.  A stalled BASE should be reopened when TARGET is resolved.
> > > When "spawning" a new TARGET i.e. through the web interface, the BASE
> > > should be stalled (if it's open).
> > >
> > I'd sort of rather that we not use "Stalled" for that, but that we 
> > actually figure out what tickets are dependent on a given 
> > ticket at runtime.
> 
> I used to be in your camp Jesse, but I think Tobias's scheme of stalling the
> BASE has some merit. Stalling means: "don't work on this ticket until
> something changes". So it implies that new transactions shouldn't be added
> to that ticket, instead they should be added to the tickets created as
> targets of the DEPENDSON links.
>

Except that's not always true. Sometimes you can do some work on a ticket with 
unresolved dependenices.  Anyway, by having this in the scrips system, it becomes site configurable.
 
> Also, if it can be done through a script, then its a non issue. The admin
> (if s/he wants it stalled) simply puts the DependsOn script in place that
> stalls the base ticket. See below for another possibile way to handle this.
> Which should be the default, I'll let you two battle over. BTW just what
> does the API for the Scrips (is that a typo? should it be Scripts?)

No. it's scrips. the API is currently "in the code" exclusively, 
though it will get documented as we get closer to release.  

> I'd argue for a monolithic script. They can always write the big script to
> call subscripts and exec the subscripts.
>
We've got a handle on it and a more elegant way to do this, I believe.
 
> 
> What about an ANSWERLINK that looks like:
> 
> 	kbfaq://kbfaqserver/....
>
KB links for MKIA, my KB server will get solidified as MKIA becomes more 
solid itself.

 
> > Interesting. I'm actually hoping to have a better 
> > inter-instance communication
> > story at some point in the future. But the auto-linking could 
> > be quite cool. what links were you thinking of?
> 
> How about something like:
> 
>   RemoteRTLinkMail
> 	mailto:rt at mailhost?[RT%20#74]:%20this%20is%20a%20ticket%20subject
> 
> then mail could be used (granted the email gateway will have to be expanded
> a bit)
> to do remote manipulation etc. Similiar links could be set up for:
> 
>   RemoteRTLinkWWW
> http://remotehost/rt/webrt.cgi?serial_num=104&display=History
> 
> and
> 
>   RemoteGnatsLink 
> 	mailto:gnats at mailhost?[gnats%20subject%20line%20with%20tag]
>

No. not for RT anyway. there will be real interfaces for inter-instance communication.
 
> -- rouilj
> 
> 
> 
> _______________________________________________
> Rt-devel mailing list
> Rt-devel at lists.fsck.com
> http://lists.fsck.com/mailman/listinfo/rt-devel
> 

-- 
jesse reed vincent -- jrvincent at wesleyan.edu -- jesse at fsck.com 
pgp keyprint:  50 41 9C 03 D0 BC BC C8 2C B9 77 26 6F E1 EB 91
--------------------------------------------------------------
Pelcgb-serrqbz abj!