Ravenbrook / Projects / Perforce Defect Tracking Integration / Project Documents

Perforce Defect Tracking Integration Project


Meeting with Chris Seiwald, 2000-08-23

Gareth Rees, Ravenbrook Limited, 2000-08-23

1. Introduction

Gareth Rees and Richard Brooksby of Ravenbrook Limited discussed options for implementing the tracker-client architecture with Chris.

The readership of this document is the P4DTI project staff.

This document is not confidential.

2. Meeting Summary

The defect tracking server may need to be a Perforce client. For example, to provide a list of opened files on the client, the server could do a p4 opened for the user's client (which it knows) and then send the data as part of the page it is serving.

If we use p4web, we could rewrite it so that it is designed to integrate with other applications. The TeamTrack interface would allocate a frame for p4web and pass in some parameters via a URL. The modified p4web would put its own pages in that frame.

Chris highlighted the trade-off between the effort on the end user's part to install, configure and run p4web versus the effort on Perforce's part to develop and maintain a browser plug-in that runs on a variety of browsers.

Chris pointed out that the re-architected version of p4web (with a minimal plug-in) is almost as difficult to build and maintain as the full plug-in architecture, since the "minimal" plug-in turns out to need to be quite a general Perforce client to do things like diff.

How is the responsibility for the interface divided? Does the defect tracker do all the interface work or does it leave some of the interface up to the plug-in? TeamTrack is designed to do all the computation and interface generation in the server. So perhaps the bulk of the tracker-client integration ought to go into the defect tracking server? We should let the defect tracking server talk to Perforce to do as much work as possible to minimize the work on the client. Only when the integration needs to talk to the disk does any instruction get sent to the plug-in.

Ravenbrook will investigate this option (the minimal plug-in) more thoroughly. If we can't make it work, our best fallback position is not to implement the tracker-client.

Figure 1. The mondo whiteboard diagram of the tracker-client architecture implementation options

A. References

B. Document History

2000-08-30 RB Created from text version of this document.

Copyright © 2000 Ravenbrook Limited. This document is provided "as is", without any express or implied warranty. In no event will the authors be held liable for any damages arising from the use of this document. You may make and distribute verbatim copies of this document provided that you do not charge a fee for this document or for its distribution.

$Id: //info.ravenbrook.com/project/p4dti/doc/2000-08-23/perforce-meeting/index.html#7 $

Ravenbrook / Projects / Perforce Defect Tracking Integration / Project Documents