This page outlines a spec for the future perforce plugin.  Much of the content comes from the hudson-dev mailing list and discussion on this topic is probably best done there. 

It was decided that a new plugin was probably needed.  The reasons for this were two fold.  First the old plugin makes use of the tek42 libraries for perforce integration.  These libraries natively invoke p4 which means that the output must be parsed.  Often unexpected output causes the appliation to crash and testing the plugin is quite tricky.  The second reason is that the current plugin is suffering from feature creep as a number of developers without a coherent vision of the plugin have been contributing over the past few years.  Some of the features are not complimentary and must be configured using checkboxes. 

What should the perforce plugin do? 

A minimalist approach is probably best and the options the current plugin provides should be trimmed.  In terms of configuration

1.  P4PORT - provide the port on which to connect to the perforce server

2.  P4USER - the user to use during the build

3.  P4PASSWD - the password to use to log in.  This could, as has been suggested, be handled by running p4 login on the build box.  However it forces people to add a script to run on their build box or manually run p4 login whenever the login ticket expires.  This parameter could be optional such that if it isn't set the plugin doesn't attempt to login and assumes that the build box and account have a valid ticket. 

4.  Workspace template - a client workspace mapping with the name of the workspace templated out.  So a workspace like

View:
        //ReleaseEngineering/trunk/... //st_mirage_installers/ReleaseEngineering/...
        //Install/trunk/... //st_mirage_installers/Install/...

would be entered as

View:
        //ReleaseEngineering/trunk/... //${clientName}/ReleaseEngineering/...
        //Install/trunk/... //${clientName}/Install/...

This would allow the plugin to create a workspace for each box which is very useful for build farms.  If the workspace already exists on the build box a new one will not be created but if one doesn't exist then it will be created from the template.  I think this approach deals with both the case of build farm and single build box.  I would probably use
something like

${projectName}
.replace("\s", "") + "" + ${buildBoxName}

as the name for the client.  

The workspace spec field will also allow the running of groovy code to generate a spec.  This should provide for installations which make use of external scripts to set up their workspaces.  

The workspace name specification, one time force sync, first changelist to track, repository browser, p4 label and windows specific details fields would be dropped. 

The repository browser and label functions could be moved into their own plugins.  The workspace name would now be automatically generated, the force one time sync should be done manually since it would be a very rare occurrence and the first changelist to track should be limited to something like p4change - 1000.