Re: [wtp-dev] Design Question: Server Commands

[Timothy Deboer <deboer@xxxxxxxxxx>]

Hi John,

Publish (or "synchronize file state")
and Start (launch the process) are separate commands because on the majority
of server types they are independant actions. Starting a server doesn't
usually mean that it is in sync with the workspace contents, nor does publish
necessarily mean that the server is started or stopped.

The only difference in server types
that has been brought forward so far is the fact that some servers need
to be started in order to publish (e.g. the server implementation uses
a remote connection to the server), which is what you describe below. Although
this is a valid requirement on the framework, I don't see this as combining
start and publish - it is just a state dependancy to be able to publish.
For servers that work like this, the server adapter includes a flag in
the plugin.xml to let the framework know. As a result, the framework will
automatically start the server first whenever it needs to publish. "Low
priority" publish requests like automatic publishing are deferred
(so that the server isn't started unnecessarily all the time) and take
place when the user manually starts the server or publishes.

Please let me know if you see any issues
with this or if you have any usability feedback on other areas of server
tools.

Thanks,
Tim deBoer
WebSphere Tools - IBM Canada Ltd.
(905) 413-3503  (tieline 969)
deboer@xxxxxxxxxx

"John Houston" <jhouston@xxxxxxx>
Sent by: wtp-dev-bounces@xxxxxxxxxxx

13/03/2006 05:09 PM

Please respond to
"General discussion of project-wide or architectural issues." <wtp-dev@xxxxxxxxxxx>

To	"General discussion of project-wide or architectural issues." <wtp-dev@xxxxxxxxxxx>
cc	Karen Stutesman <kstutesman@xxxxxxx>
Subject	[wtp-dev] Design Question: Server Commands

I have a question about WTP’s expected behavior
for server commands when server models might not apply for those commands.
Specifically, I’d like to know about “Publish” vs. “Start.” 
 
For the Tomcat server model, “Publish”
is to deploy web artifacts into a Tomcat runtime, whereas “Start” is
to kick off a server process to run the deployed files. Here, “Publish”
and “Start” are independent – a user can start a Tomcat runtime without
deploying files, and a user can publish (or deploy) an app without starting
the server process.  
 
But is that still the expected behavior of
these commands for servers that don’t necessarily fit into that model?
For example, if it doesn’t make sense for a server to publish without
starting the server (in other words, the publish and the start are very
closely tied together), then should the server runtime extension developer
work into that model (“Publish” to a temp directory, for example) or
should the server runtime extension developer treat the commands as a “best
fit”  (“Publish” will leave the server in a started state)?
 
The UI developer in me sees the architecture
from the UI POV and thinks that a UI with commands that behave significantly
differently is typically a red flag for a poor UI. On the other hand, I
understand that a “best fit” model is more true to the commands that
a server runtime offers. Here are the options as I see them:
1-
      Work the server instance
into the existing “Publish” / “Start”  system
2-
      Let the “Publish”
/ “Start” commands mean different things depending on runtime type
3-
      Submit a patch to
update the UI so that “Publish” / “Start” are extensible to other server
publish models
 
Can you provide me with some background about
how the “Publish” / “Start” system came about and which option might
be best of the above options? 
 
-- John

_______________________________________________________________________
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.
_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev