On Feb 28, 2007, at 9:59 PM, Luciano Resende wrote:
While reviewing contribution code and thinking about some test
scenarios, I
have the following questions and would like to get some thoughts.
1.What should be the default behavior when i re-deploy a
contribution to the
repository ? Should it replace the existing application, or an
exception
should be thrown ?
It should be duplicated - they are two separate contributions of the
similar things. If the two items are identical, then you can silently
drop the duplicate; if they are not identical then they are two
different versions of something.
2.When you re-deploy a contribution, should it get a new
contributionId ? or
continue to use the same ?
A different contributionId as that is how a user can tell them apart.
3.When deploying a folder contribution, should we support store this
contribution into the repository ?
Generally yes (including copying it) as in a production system you
would not want inadvertent changes to the source disrupting service.
You will also generally want to archive it up for distribution around
the federation.
At development time though things are different as you want changes
made by the developer to be reflected quickly without them having to
stop/package/redeploy/start all the time. This really requires much
closer integration between the IDE and the runtime than the
contribution service provides (for example, the IDE could interact
with the runtime to rebuild individual components).
4.In contributionService, do we really need to pass the InputStream
for the
contribution service ? would we have scenarios where we will not be
able to
access the contribution via it's url / uri ? I'd like to leave to the
contribution to decide really when it would be necessary to open
the streams
to probably have a better performance and use less resources.
Yes - the most likely way a contribution would get to a production
server is though a transport like HTTP POST. It is very unlikely that
a remote server will be able to initiate a connection back to a client.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
