[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[alf-dev] RE: Special ALF SCM Vocabulary Meeting 09Oct2006 - meeting minutes
|
Special ALF SCM Vocabulary meeting minutes
Attendees:
Tim Buss
Brian Carroll
Mark Phippard
Richard Title
Adam Simatel
Agenda
We reviewed the various suggestions as a way to start on this (see
attached email and repeated below as item titles).
Minutes:
1. CreateWorkspace/ModifyWorkspace/RemoveWorkspace: For
completeness, also need a ShowWorkspaces. Similar comment applies to
many of the other Create* methods. Also, for consistency with the other
API's that take a workspace as input, ModifyWorkspace should take a
"Workspace workspace" argument rather than a "String workspaceName"
argument.
This was generally agreed but....
Generally we prefer the term "list" to "show"
There should be a way to get a single item (eg: a "get"
operation) since this is the most likely use case in ALF.
Possibly a list operation would just return a list of ids and a
get would return the more complete "meta data".
For lists that are expected to be small, possibly all the meta
data can be returned in the list.
A list "filter" could allow the same operation to return the
single item.
List operations (and operations in general) will only provide
the data that the caller is authorized to see according to the SCM. ALF
will provide a authentication credential or token of some sort that the
tool will use to drive its authorization model (see item 9.)
There was some discussion as to whether the workspace service or
the SCM server service could list workspaces. There are two cases.
Listing the workspaces that a workspace service is managing locally to
it. Listing workspaces know to the server globally. This requires
further discussion.
2. AddAssets/RemoveAssets: For completeness, should have a
ListAssets which would list assets (elements) under version control. It
should take a Workspace or Stream as input, and produce a directory
listing of the elements that are under version control in that workspace
or stream.
Listing assets could return a very large list. We would need to
provide an interface that could deal with this an segment the list. It
is not clear that listing assets in this way is that useful in ALF to we
may prefer to defer this to later.
3. RemoveAssets should probably take a Workspace rather than a
Stream, on the theory that asset-changing operations (e.g.
add/create-new-version/remove) all should be done through a workspace.
The general model should be that you do work in workspaces, and changes
only get into streams by promoting.
Remove is required for every create to support compensation. The
more useful case would seem to be against the workspace since it is
generally the model to edit the workspace and then commit the changes.
Some SCMs may have a direct asset remove on the server that would not
require a workspace to use. This requires further discussion.
4. IntentToModify ("checkout") should have an inverse operation
("uncheckout"), for the use case where you check out something but then
change your mind. Let's see, should we call it the NeverMind() method? J
Also, I think this is implied, but we should say explicitly that
CreateNewVersions ("checkin") releases the checkout for the specified
elements.
This is required to support compensation
5. CreateStream: For completeness, we should have a ModifyStream
and RemoveStream.
Remove Stream is required to support compensation. It is unclear
what Modify stream would do so we will wait to see what is needed to
define it
6. CreateBaseline: This should take an optional Workspace argument
also. We should allow the caller to specify either (a) Just a workspace
(baseline is current contents of the workspace), (b) Stream (baseline is
latest versions in the given stream, or (c) Configuration (the result of
applying the given Configuration rules). Only one of these 3 should be
specified, or else the baseline is over-specified.
The idea is that you could create a baseline from the workspace
config and providing the workspace would be a shorthand for this. This
seems fine
7. UpdateWorkset: Should be UpdateWorkspace. Also, should make
clear that "baseline", "stream", and "configuration" arguments are all
optional and the normal case is to update the workspace from its
already-defined configuration, e.g.
UpdateWorkspace(
Repository repository, //
Workspace workspace, //
Baseline baseline, // (optional) if fetching
versions from an existing baseline
Stream stream, // (optional) to fetch latest
versions in the given stream/branch
Configuration configuration, // (optional) overrides
workspace's config-spec to specify what versions to fetch
Options options, // standard options such as
refresh, replace, etc.
OtherOptions otherOptions // tool specific options
)
This seems fine
8. Need an API to create/modify/remove Components.
We had previously agree to defer "components" so we will defer
this
9. Need to (somehow) deal with user-id's, authentication (a
"Login" method), and ownership of assets (pass explicit user-id's, or
get implicitly from logged-in user at time of Create* operation?).
List operations (and operations in general) will only return the
data that the caller is authorized to see according to the SCM
authorization model. ALF will provide a authentication credential or
token of some sort that the tool will use to drive its authorization
model.
There are three mechanisms for communicating an authenticated
"credential" to the SCM service (or any service)
a. ALF SSO - the preferred mechanism - leverages
WS-Security et al and SAML to deliver a credential to the service in the
SOAP header.
b. The cookie method. Services can use cookies whereby
the provide a login and logout operation and all service. The login
establishes a cookie which the caller must cache and return on each
subsequent call until logout.
c. The explicit method. An authentication credential (eg
a authenticated session token) is passed explicitly with each service
call.
a. and b. potentially allow security to be implicit since no
explicit authenticated token is required by the general services. The
cookie method can provide a good migration path to the SSO method for
this reason.
for method c. it is suggested that we leverage the ALF required, ALF
specific parameter providing an optional element than can be used to
pass credentials explicitly. Since all vocabulary operations will take
this argument it provides
a consistent and non intrusive method.
10. an ALF specific parameter. This should hold various IDs that
should be returned by the tool on any event that it raises as a result
of the call. This is used to set the "previousEvent" field in the event
structure and to provide an id for Correlation to facilitate callback.
I don't think there is a suitable ID currently although event ID could
be part of it. We should to discuss possible formats for this
structure. It will probably be common to all ALF vocabularies. The
Base ALF event structure is probably a good place to start.
This parameter is given to every ALF vocabulary operation. So far we
have identified the need for it to contain
a. The current event ID to allow the tool to set
"previousEventID" in any resulting event
b. A id that identified the Service Flow instance to initialize
and identify a "correlation set" and allow "callback" from the tool to
the same Service Flow instance
c. An optional security credential/token.
11. Return/response messages
Methods that create object should return a least the unique
object ID to allow the object to be addressed.
Responses should be used for returns/ statuses that might be
expected as part of the usual business logic (eg Build failed) where
there is a usual business intent for handling the case. In this example
the purpose of build maybe to determine if the source can be built. If
it cannot different business logic applies.
12 Faults
Faults should be used for unexpected returns, such as security
access failure, where you would not normally expect to handle the
failure as part of the business logic. Faults are best when the likely
response is to try to use compensation to back out any preceding
changes
Most things just succeed or fail in an unexpected way so a
commonly defined "status" element may not be that useful in practice.
There may be some cases where it is not clear which type of response
(response vs fault) should be provided but this can only be determined
case by case.
13. Datatypes
A first pass at datatypes has been captured in the SCM schema.
This requires review and appropriate updates
We will continue this discussion in a regular Wednesday meeting this
week. As always let me know if I failed to capture anything important.
Tim Buss
Serena Inc.
________________________________
From: Tim Buss
Sent: Monday, October 09, 2006 8:56 AM
To: 'ALF Developer Mailing List'
Cc: 'markp@xxxxxxxxxxxxxxx'; 'rtitle@xxxxxxxxxxx'; 'etm@xxxxxxxxxxxxx';
'Glenn.Everitt@xxxxxxxxxxxxx'; Adam Simantel; Brian Carroll; 'Steve
Taylor'
Subject: Special ALF SCM Vocabulary Meeting Today at 10:00 PDT
+1-303-928-3232 id 6053141#
>From Last weeks meeting minutes
T24 Refine and Normalize Operations so they work as a coherent set
Assigned to you.
We agreed to a special meeting set for 10:00am PDT on Oct 9th to focus
on this issue and T29 "return values and faults"
Apologies for the late reminder.
Tim
**********************************************************************
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
--- Begin Message ---
- From: "Tim Buss" <TBuss@xxxxxxxxxx>
- Date: Mon, 9 Oct 2006 09:53:09 -0700
- Thread-index: Acbrva21ekLvEAWrQwKQQkZnAeX5fwAAJ+YAAAEnC7AAABJxEA==
- Thread-topic: [alf-dev] rounding out the API in the SCM Vocabulary wiki
oops sorry Richard. I meant "Thanks Richard"
Tim
________________________________
From: alf-dev-bounces@xxxxxxxxxxx [mailto:alf-dev-bounces@xxxxxxxxxxx]
On Behalf Of Richard Title
Sent: Monday, October 09, 2006 9:50 AM
To: 'ALF Developer Mailing List'
Subject: RE: [alf-dev] rounding out the API in the SCM Vocabulary wiki
Agreed. Except for the first sentence which should say "Richard". :-)
________________________________
From: alf-dev-bounces@xxxxxxxxxxx [mailto:alf-dev-bounces@xxxxxxxxxxx]
On Behalf Of Tim Buss
Sent: Monday, October 09, 2006 12:30 PM
To: ALF Developer Mailing List
Subject: RE: [alf-dev] rounding out the API in the SCM Vocabulary wiki
Thanks Adam
Other things we need are:
1. an ALF specific parameter. This should hold various IDs that should
be returned by the tool on any event that it raises as a result of the
call. This is used to set the "previousEvent" field in the event
structure and to provide an id for Correlation to facilitate callback.
I don't think there is a suitable ID currently although event ID could
be part of it. We should to discuss possible formats for this
structure. It will probably be common to all ALF vocabularies. The
Base ALF event structure is probably a good place to start.
2. return values - really response messages. Most operations will
provide a synchronous response of some kind even if they later raise an
event.
3. faults - we need to define a common format for vocabulary specific
faults and come up with a set of faults for the SCM vocabulary.
Tim
________________________________
From: alf-dev-bounces@xxxxxxxxxxx [mailto:alf-dev-bounces@xxxxxxxxxxx]
On Behalf Of Richard Title
Sent: Monday, October 09, 2006 9:12 AM
To: alf-dev@xxxxxxxxxxx
Subject: [alf-dev] rounding out the API in the SCM Vocabulary wiki
First off, apologies for not being that active on the ALF lists lately -
I've been busy getting AccuRev version 4.5 out.
I was looking over the API defined in
http://wiki.eclipse.org/index.php/ALF/SCM_Vocabulary (the Java
pseudocode in section 5) from the point of view of whether it is a
complete/consistent/usable SCM API. Generally it seems to be taking
shape nicely. Here are some details-level comments. I can go in and
correct these myself, but I wanted to get consensus from the larger
group first.
1. CreateWorkspace/ModifyWorkspace/RemoveWorkspace: For
completeness, also need a ShowWorkspaces. Similar comment applies to
many of the other Create* methods. Also, for consistency with the other
API's that take a workspace as input, ModifyWorkspace should take a
"Workspace workspace" argument rather than a "String workspaceName"
argument.
2. AddAssets/RemoveAssets: For completeness, should have a
ListAssets which would list assets (elements) under version control. It
should take a Workspace or Stream as input, and produce a directory
listing of the elements that are under version control in that workspace
or stream.
3. RemoveAssets should probably take a Workspace rather than a
Stream, on the theory that asset-changing operations (e.g.
add/create-new-version/remove) all should be done through a workspace.
The general model should be that you do work in workspaces, and changes
only get into streams by promoting.
4. IntentToModify ("checkout") should have an inverse operation
("uncheckout"), for the use case where you check out something but then
change your mind. Let's see, should we call it the NeverMind() method?
:-) Also, I think this is implied, but we should say explicitly that
CreateNewVersions ("checkin") releases the checkout for the specified
elements.
5. CreateStream: For completeness, we should have a ModifyStream
and RemoveStream.
6. CreateBaseline: This should take an optional Workspace argument
also. We should allow the caller to specify either (a) Just a workspace
(baseline is current contents of the workspace), (b) Stream (baseline is
latest versions in the given stream, or (c) Configuration (the result of
applying the given Configuration rules). Only one of these 3 should be
specified, or else the baseline is over-specified.
7. UpdateWorkset: Should be UpdateWorkspace. Also, should make
clear that "baseline", "stream", and "configuration" arguments are all
optional and the normal case is to update the workspace from its
already-defined configuration, e.g.
UpdateWorkspace(
Repository repository, //
Workspace workspace, //
Baseline baseline, // (optional) if fetching
versions from an existing baseline
Stream stream, // (optional) to fetch latest
versions in the given stream/branch
Configuration configuration, // (optional) overrides
workspace's config-spec to specify what versions to fetch
Options options, // standard options such as
refresh, replace, etc.
OtherOptions otherOptions // tool specific options
)
8. Need an API to create/modify/remove Components.
9. Need to (somehow) deal with user-id's, authentication (a
"Login" method), and ownership of assets (pass explicit user-id's, or
get implicitly from logged-in user at time of Create* operation?).
That's it. If people agree generally, I can volunteer to update section
5 of the SCM Vocabulary document in the Wiki.
Richard Title
AccuRev
**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed. Any unauthorized review, use, disclosure or distribution is
prohibited. If you are not the intended recipient, please contact the
sender by reply e-mail and destroy all copies of the original message.
--- End Message ---
