I am off to Boston for a copuple of weeks, so I won’t be able to participate
in this discussion till I come back on 12 May.
I think we more or less have a concensus about what links should be
available for 2.0, and how they should behave:
…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.
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?) systems
look like? One monoloithic script that handles all linking actions could
have an CLI like:
linkscript BASEID TARGETID action OtherArgs
where action would be: CreateLink, TargetIsResolved, DeleteLink,
NewTargetPriority … OtherArgs affect the operation of the linscript e.g.
StallBaseTicket. The linkscript that implements appropriate linking actions
(distribution scripts written in perl of course) does all the real work
using the perl api’s. If the user wants other types of links, fine. They can
write them in whatever language they want using the rt cli to do the actual
operations in rt.
Or you can split each action to its own script:
linkscript.create BASEID TARGETID
linkscript.TargetISResolved BASEID TARGETID
I’d argue for a monolithic script. They can always write the big script to
call subscripts and exec the subscripts.
This means that when TARGET is resolved, all BASE is automagically
resolved. When a support worker sends correspondence on a TARGET, all
BASE requestors should receive the correspondence. If all BASEs are
resolved, TARGET should automaticly be resolved.
I disagree. MemberOf shouldn’t automatically resolve either
BASE or TARGET. There should be a way to “Resolve all members” or
Maybe another link type? There is nothing to say that there can’t be
multiple links between two tickets. Remember that actions/relations are
implied by the links.
A link that causes the BASE to be resolved when the TARGET is resolved may
very well be a separate action that they want performed. I’ll agree that
multiple links in a rational way is a bit tough, but I think it adds a lot
of flexability to the system. I’ll see if I can come up with some ascii
visualization method that will work.
This is Jesses domain. I’m not sure if it makes sense to have this as
a link. Anyway, it should me the same as the “merge” of today.
The thought was that for 2.0 “merging” should become just
another linking type that did intelligent things with the requestors
for each ticket, to make it easier to track history, among other things.
Agreed. MergeInto definately should have the semantics that resolving TARGET
also resolves BASE if BASE isn’t a base for links whose tickets are open.
The exact semantics gets a bit tricky here, because closing a BASE for a
simple link has no
ramifications, but closing a BASE for a DEPENDSON link whose target isn’t
is a problem. Again this can be handled by changing a small script rather
than by changing the core code, so its not as big a deal as it could be.
A “simple” link, just stating that two things are related somehow. It
shouldn’t have any special behaviour.
Just the ability to print the simple links given base or target ticketID’s.
I think the behaviours mentionated above can be executed through the
Scrips system. I think the system, as it is in the current CVS
version, is good enough (though more documentation is needed to be
Cool. That would make it a nice modular system that was easy to adapt.
Hrm. If you did this, then I could set things up to not
perform the weird actions
Agreed. Actions should be linked to link types and be modifyable at the end
site, not built into the core.
It’s possible that we will need more linking actions, but not until
after 2.0, I’d daresay.
nod I’ll buy into that.
Agreed. I think all of the 4 types of links I identifed have been covered.
The ID’s should be animals that can be given to RT directly (either in perl
command line), or they should be parsable into method, host, id, args quads.
I think URI’s are perfect:
BASE and TARGET are usually Tickets within one RT instance, but it
might also point to external RT instances, other DB systems, etc.
Most important for us now is to get links between RT and the KB/FAQ
system (must be handled especially in the web interface; we want it to
be possible to easily launch semi-automatic answers through the web
interface) and between RT and Bugzilla.
What about an ANSWERLINK that looks like:
the : will immediately determine that its not a local rt link (they consist
only of numbers). The kbfaq implies that some kbfaq method of access has to
be used. Not being familiar with kb/faq I hesitate to elaborate further.
There may be some times of links that shouldn’t or can’t be made remotely.
E.G for development use a link to a file may be represented as:
This isn’t any worse than links to other databses, or rt instances. All of
them have the problem that there is no way to insure that the TARGET of a
The mailgate should automaticly detect mail from other RT instances
and set up a link. Communication between two RT instances should
mainly be done through the mail gateway. It might make sense to allow
web users to access remote RT instances “seamlessly”.
Interesting. I’m actually hoping to have a better
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:
then mail could be used (granted the email gateway will have to be expanded
to do remote manipulation etc. Similiar links could be set up for:
the list is endless. I do think that the URI format can be used to encode
the proper info. What to do with the info, or how to display it can be
shifted off to scripts as well:
RemoteGnatsLink LOCALRT_TICKET_ID TargetGnatsLinkURL DisplayTarget
and DisplayTarget target can do:
return a real URL that can be clicked on maybe with < A href=…>
text explaining how to access it manually for dummy access methods.
BASE and TARGET is shaped like URLs. This is one of the things I’d
like to discuss. Here’s Jesse’s idea:
Well. I’m a bit positive, but I’m absolutely not sure. The "url"
above can’t be used for anything, as long as it doesn’t contain more
data about how to communicate with (instancename). It might be a good
idea to have something like this if there exist a mapping from the
instancename to such information somewhere. Anyway, I wouldn’t call
it an “URL”, as it is “broken” without this extra information. Any
Hrm. If it became instancedomain/instancename then DNS srv records could
be used for glue. I don’t think that would suck too badly
I would write the fsck.com-rt link as either:
as I have above. Both are perfectly resolvable, and can be further
manipulated into url’s that will work. Also the DisplayTarget (and maybe
DisplayBase) code can do arbitrary mapping even turning fsck.com-rt:… into
one of the above forms.