[news.eclipse.technology.alf] Meeting minutes for the ALF Source Code Ma

["Tim Buss" <t b u s s @ S e r e n a . c o m>]

Meeting minutes for the ALF Source Code Management Vocabulary Meeting on
Wednesday Aug 2nd at 10:00AM PDT

Agenda

0. Last meetings's minutes

1. Status on tasks (see list in minutes below)

2. Progress on the Data model and Schema and WSDL

3. Revision Specification (see T21)

4. Any other business

Attendees

Tim Buss

Mark Phippard

Adam Simantel

Robert Reising

0. Last weeks minutes were accepted. No additional comments were noted.

1. Tasks

Completed

T15.

Expand "primitive" use cases to include more detail (eg datatypes, method
signatures) Richard made some updates. Adam committed to update the items he
signed up for and resend the email soliciting for volunteers to address the
remaining items

This is essentially done for now. The task now is to refine what we have. I
have created a new task (T24).

T17.

Create a schema from the data model.

Tim has create a set of type definitions from the main data model and
workspace.

Workspace still needs to be addressed. Revision Specification need more
discussion (see T21) A first draft has been added to the wiki for review.

T21. Refine the idea of "Revision Specification". Define the common use
cases.

There are several ways this could be expressed. For example:

A) as an opaque string to ALF

B) as a formal set of "objects" that can be related in some formal way

C) as an ALF defined "language string

D) some combination of above.

It seems that there are some common use cases (eg get "latest" from

branch) that should be defined explicitly by ALF but there are many other
cases. It seems unwise for ALF to attempt to define a fully generalized
approach. For this cases ALF should just allow the underlying tool to extend
the ALF services or provide tool specific services. We need to decide what
cases make sense for ALF to formally define.

This was discussed today. See meeting notes below.

T22. Create WSDL for operations

A first draft has been created and added to the wiki for review

Todo

T19

Wiki pictures. There are some placeholders for pictures in the Wiki.

These need to be populated. In particular it would be good to get the
updated data model into the Wiki

T23 Define SCM events XML

Assigned to Tim

T24 Refine and Normalize Operations so they work as a coherent set Assigned
to you. Please provide feedback

T25 Reflect Operation refinements in Schema and WSDL Assigned to Tim

T26 Discuss dynamic "Callback" idea

A point was raise that perhaps raising an ALF Event for every asynchronous
action completion may be too heavyweight. An alternative using a dynamic
callback service passed with the operation was suggested. This would
probably tale the form of an ALF event in definition but would connect back
to the calling instance of the service flow directly. The removes the need
to create new service flow instance and simplifies data correlation in some
cases.



2. Progress on the Data model and Schema and WSDL A first draft schema and
WSDL have been posted to the Wiki. Please review and provide comments and
questions.

3. Refine the idea of "Revision Specification". Define the common use cases.

The notion of "Revision Spec" applies to any "query" specification that
locates a set of one or more Element versions. The main question is whether
it is useful for ALF to able to dynamically create such specs and to what
level of complexity.



The main operations this appears to apply to are "UpdateWorkset" (Workspace
really) and "reporting". We have decided to defer considering reporting for
now.

For the Workspace we think it more likely that a pre-defined configuration
is the most useful for ALF. That is, ALF would not typically dynamically
build a "Revision Specification" to populate a workspace but would pass in a
tool specific configuration that the workspace service would use to populate
itself. We agreed that ALF probably doesn't need to know (or specify) the
details of this and that the tool specific configuration can in most cases
be opaque (ie a string) or hidden from ALF (ie a name that references a
configuration)

That said there may be common cases that may be convenient for ALF to
dynamically specify. These are likely to be fairly simple (eg Tip of branch,
this Label, this baseline ) and ALF could define with reasonable confidence
that most implementations can support them. ALF would not define a way to
combine these into a single workspace specification

(Note: I suppose as an optimization we might suggest that these be used to
define a sequential list as a short hand way of saying "get this, get this,
get this". This seems useful for ChangeSets in particular. I'm thinking
something like a sequence getBaseline, getChangeset 1, getChangeset 2....
Combined into a single call)

We think that the most useful AddVersion, NewElement type of operation for
ALF is to ask the Workspace to "commit" based on its current content. In
this way once the workspace is configured ALF doesn't need to be concerned
about the detail of what actually gets committed and how that gets
specified.

(Note: this idea was discussed in the Build Vocabulary meeting and seems to
be compatible with the ideas there. The notion of reports was discussed and
it does occur to me that workspace content provides a useful "report source"
for many cases and it may be useful to allow the workspace "tree" to be
walked at a logical level to provide specific information and provide an XML
"report" of its tree for the complete content report. The workspace could
provide the tree data either by caching the meta data when it materializes
the elements or by running a "query" on the server as if it were populating)

We also agreed that much of the detail for this will come from refining the
operation definitions and that that should be the next step.

4. No other business was raised.

Tim Buss - Serena.