MEETING WITH GLYPHIC, 2000-08-21 Gareth Rees, Ravenbrook Limited, 2000-08-21 1. INTRODUCTION This document describes a meeting between Richard Brooksby and Gareth Rees of Ravenbrook Limited and Leslie Smith and Mark Lentczner of Glyphic Technology. The purpose of this document is to record design decisions for the integration (and constraints on the design) relating to Glyphic's Perforce plug-in technology. The intended readership is technical staff at Ravenbrook and Glyphic. This document is not confidential. 2. WHAT CAN PLUG-INS DO? We need to decide on our browser platforms that we'll target. We're really talking about supporting only Netscape 4.0 or Internet Explorer 4.0 on Windows or Unix. Can we have an "atomic" Perforce submit and TeamTrack case transition? 3. NUMBERED PENDING CHANGELISTS Submit is a problem with integrations. In most applications the user picks some objects, adds a comment and then submits them. But in Perforce you say "submit"; then the Perforce server asks you what exactly you want to submit; then you pick what you want to do. But numbered changelists don't work well. They weren't designed with users in mind; they were designed to solve a problem with the server. When you do a "p4 submit -c nnnnn" you don't get an opportunity to change the changes you are submitting or to edit the comment. The problem with changing the server is that the clients have expectations about how numbered changelists work. For example, none of the plug-ins support numbered changelists. No IDEs have the ability to allow you to relate your edits to a job when you start typing in a file. (We could insert user interface here but it will be very tricky.) 4. CLIENTS If you do everything with depot filenames then you don't need a client. As long as you're viewing and diff2ing, then Perforce doesn't need a client. So we can support read-only stuff without clients. But for anything more complicated the user needs to indicate what the context is: are they syncing the whole of the project in order to build it or are they just editing a single file? 5. SOLUTIONS 5.1. Helper application The simplest approach is to extend the command-line client so that it works as a helper application. Problems: output doesn't look nice, it's a pain to download and configure, it's not going to be possible to do submit-and-transition. 5.2. Plug-in Build a plug-in combining the Perforce interface and Glyphic's plug-in interface. This would provide user interfaces for things like clients, jobs, etc. However, this doesn't work on Unix. Glyphic haven't worked out what X widget sets they are going to support, if any. However, the user base for the tracker-client architecture probably aren't Unix users (or if they are, it is less important for them to be able to stay in their browser to do version control operations). 5.3. Connect to existing p4web Connecting to the existing p4web wouldn't meet the user requirements for the integration. It wouldn't add any Perforce functionality to the TeamTrack interface, since it isn't written in a way that supports use by other applications. (There are no templates, for example.) 5.4. Write a Java implementation Too difficult? 5.5. Connect to a re-architected p4web Another possibility would be to re-architect p4web so that it has a web server on the Perforce server, then the browser would be able to connect to the p4 web server. There would be a very tiny plug-in that actually gets the files onto the client disk. This could be as simple as the p4 command-line client. Could provide both plug-in and helper application support. This would be a lot of work. In this scenario we would set up the defect tracking web server so that it can point users at URLs in the Perforce web server. The stub would be very small and simple. The Perforce web server would provide any interface components. (The stub may not even need to connect to the Perforce server -- it could send the files round via HTTP -- but in practice it's a good optimization to connect directly.) However, this would require major changes to the p4web architecture; it is probably too hard to contemplate doing as part of the P4DTI project. 6. INTEGRATING WITH THE IDE Recall that numbered changelists aren't supported in the IDE. In the plug-ins, there is a global configuration option as to whether jobs appear in the submit form. This is off by default, so we'll have to write some installation instructions telling people to turn it on. In the plug-in interface, the job view comes out as a text field. The interface doesn't really know about jobs -- it just presents the form fields that the server send it. (It's smart about the filespec field.) Our documentation ought to mention job views. How does someone in the IDE get the list of jobs they need to work on? In Developer Studio there is no way to see the list of jobs. In CodeWarrior Glyphic have added a command for running any p4 command. So in this case we can people how to get at their jobs. 7. PLUG-IN SCHEDULE Mark estimates that to adapt their plug-in to conform to browser interface will take one month of effort. Some investigation is required about how to return results to the browser. 8. MORE THINGS TO THINK ABOUT We don't have an item in the plan for making "add" changes work from TeamTrack. This is likely to be harder than "edit" changes. We don't have a requirement for administrator overhead. There's some analysis under the heading of requirement 1, but we need to add a separate requirement and cross-reference it. Mark hinted that we may be able to do two-phase commit by locking on the Perforce side. Is this really possible? We need to investigate. The Python dictionary stuff is nice, but it would be much better to document the existing interface to the server (in terms of what messages are sent and what information they contain) and make sure that it's designed to be maintainable and adaptable. Note that most users don't use jobs -- so we're really pushing the limits of what Perforce can do. We can expect to see problems. A. REFERENCES [GDR 2000-08-21] "Meeting with Glyphic, 2000-08-21" (e-mail message); Gareth Rees; Ravenbrook Limited; ; 2000-08-21. [Lentczner 2000-09-11] "Re: Meeting with Glyphic, 2000-08-21" (e-mail message); Mark Lentczner; Glyphic Technology; ; 2000-09-11. B. DOCUMENT HISTORY 2000-08-21 GDR Written during meeting as [GDR 2000-08-21]. 2000-09-11 GDR Edited to remove confidential material. 2000-09-12 GDR Edited to deal with comments in [Lentczner 2000-09-11].