[rt-devel] Re: Remote linking

Jesse jesse at fsck.com
Wed Apr 26 14:42:57 EDT 2000

On Wed, Apr 26, 2000 at 08:27:35PM +0200, Tobias Brox wrote:
> > The UI isn't for _viewing_ a ticket, but for allwoing RT to know where a ticket is.  
> > 
> > But yes, for a queue uri, we'd get <instance name>/queue/<queue id>
> I was almost about to buy it, but then ... not really :)
> In this case we merely want to construct an URI that should reference a
> ticket (or anything else).  That's what we need right here and now.  I
> can't think of any needs for it at the moment - but anyway I really think
> it would be shortsighted to do it in such a way that it will not be
> possible to construct "fsck.com-rt"-URIs that can be used for viewing a
> ticket, performing actions with one or several ticket(s), or just
> whatever.

The goal of the URI  is merely to be a pointer to the data. Nothing more.
RT or other apps that wish to do so should have the logic to construct Procedure calls, mailto links, http links or whatever they want.

> With the path construct above, this will break.  It's not easy to 
> construct an easy to read, consistant and truely unambigious URI that
> contains all the wanted data.  Parameters are better than a path.  So I
> would say something like
> 	fsck.com-rt://$domain/instancename?ticket=$ticket
> 	fsck.com-rt://$domain?ticket=$ticket
>  	fsck.com-rt://$domain/instancename?queue=$queue&keyword=$keyword&action=resolve
> 	(etc)

Now you're getting into RPC issues. This is a wholle seperate problem that I've been thinking about a whole lot lately.  After we get RT2 out the door, we should
definitely start looking at how to do RPC nicely. But using URIs misses the point, i think.
> 	or, if you really dislike ? and &, maybe this is better
> 	fsck.com-rt://$domain/instancename/ticket=$ticket
> 	fsck.com-rt://$domain/instancename/queue=$queue
> 	(etc)
> About the relationship between the fsck.com-rt URI and other URIs ... the
> fsck.com-rt URIs should always be possible to convert to URIs starting
> with "mailto" or "http" or maybe even "tcx.se-mysql" based on information
> stored in the svc records and/or a configuration file and/or the database
> and/or whatever.

The URIs should always contain enough info to figure out what object you're talking about and where it lives. No other information should live in the URI.
> > Yeah. The problem is that instance names don't map cleanly to domains.
> > maybe it should be fsck.com-rt://domain/instancename/ticket/number
> Instancename should be optional, I think.  Most domains/subdomains have
> only one instance running, I'd daresay.
It may be that the base case is that there's only one instance for a given domain, but that instance often has a name that has little to do with the domain. The goal of having the instance name in there is to be able to look up the instance's information in SRV records or a local lookup table or whatever.
> -- 
> Tobias Brox 
> aka TobiX
> +47 22 925 871
> _______________________________________________
> 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
  "Mary had a crypto key / She kept it in escrow
     And everything that Mary said / The Feds were sure to know" -- Sam Simpson 

More information about the Rt-devel mailing list