[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[stellation-res] Status / Issues for STIM
|
(Note: per Mark's suggestion, I'm moving this thread to the public
Stellation list.)
At 10:43 AM 8/14/2003, Mark C. Chu-Carroll wrote:
On Wednesday, August 13, 2003, at 05:22 PM, Jim Wright - IBM Research wrote:
I've fixed a number of bugs in STIM recently, and added a
'refresh' menu option intended to remove any stale conflicts.
As it happens, the refresh option doesn't work very well; rather,
it's revealed some apparent inconsistencies between the internal
task server state and the state as reported and/or retained by the
STIM client. (Problems could be client-side or server-side, of course).
There are also some issues w.r.t. reconciling client state with
task server state, for name, description, and other attributes.
I think some additions to the task service protocol would be
pretty helpful:
a) a message advising when a task unreserves one or more resources.
The mesage should be sent to (or at least indicate) tasks which still
have a reservation for the resource(s) concerned.
This really won't scale well. Consider what happens when you've got hundreds
of users and thousands of tasks... You'll have non-stop messages about
reservations
appearing and disappearing.
I guess I didn't explain very well......
currently, tasks are notified when a resource conflict is created (by
another task
reserving the same resource).
However, a task is _never_ notified when the resource conflict goes away (e.g.
because the conflicting task has been completed, or perhaps no longer needs to
change a previously-reserved resource).
This means that the client may well show a conflict for a task when, in fact,
no conflict still exists.
Joe reserves StimTask.java, for feature task DetailUpdate
Fred reserves StimTask.java, for bug task ResourceRefreshIsBroken
>> task server sends conflict messages to Joe and Fred.
Joe and Fred chat; Joe decides to wait until Fred has the bug fixed
(even though Joe reserved the file first).
Joe unreserves StimTask.java
>>> Fred's Task view __still__ shows a conflict for StimTask.java,
even though the task server state now indicates no conflict for that resource.
There are two possible solutions:
1) Enable Fred to manually refresh resource conflict info for his task.
This seems kludgy to me, and as error-prone as any manual procedure.
Also, the current message to queryTasksReservingResources only
retrieves task IDs. The _conflict_IDs are at least as important
(e.g. for cross-referencing to chat transcripts, etc.) -- but I can't get them,
except perhaps by deactivating and reactivating the local task, which will
presumably send a flood of conflict messages to all other tasks reserving
any resource used by said local task, upon its reactivation.
2) Have the task server advise the relevant tasks -- and _only_ those tasks -
when a resource reservation is _released_ . This seems better to me.
For example, assume Fred, Joe and Sally each have a task reserving Foo.java.
They have all (presumably) received conflict notifications indicating the
three tasks that all want Foo.java.
[At this point, the Stim task view would show two conflict icons attached to
Foo.java, one for each of the other two tasks. For Fred, the view would
show conflicts with Joe and Sally; for Sally, the view would show conflicts
with Fred and Joe, etc.]
Note that Sally double-clicks the 'Joe conflict' icon to request a chat
with Joe,
and double-clicks the 'Fred conflict' icon to request a chat with Fred.
Transcripts of previous chats with Joe or Fred, about this conflict, will
(in future)
also be accessible from the respective conflict icon.
Now, assume Joe unreserves Foo.java. Fred and Sally should get a "conflict
changed" message of some kind, indicating there is now only a two-way
conflict, involving tasks owned by Fred and Sally.
[At this point, Joe's task view will no longer include Foo.java. The task view
for Sally will show a single conflict (with Fred), while Fred's view will
show a
single conflict with Sally.]
Now, Fred unreserves Foo.java. Sally should get a "conflict cleared" message
indicating that Foo is now hers and hers alone.
[At this point, Sally's task view will show Foo.java with no conflict icons
attached].
Aside: it will still be possible to access chat transcripts and other
conflict history information
from the Foo.java task view icon, via the right-click context menu.
This is why I've suggested a "resource unreserved" message (or a pair of
'conflict changed' and 'conflict cleared' messages). Without them, I
cannot automatically
keep the task views up to date.
As far as scaling is concerned --- reserving and unreserving resources
should involve about
the same amount of message traffic. So, worst case the message traffic is
doubled.
As you've said elsewhere, we should probably overhaul the messaging system
to use
target-based subscription management (see Stellation Wiki: ProjectPlans >
SubscriptionManagement).
This should keep the traffic to manageable levels.
The alternative likely involves periodic pinging (client->server) to see if
anything changed.
Imagine the traffic when the client queries **every** resource owned by a
given task, to
see if the conflict status of any resource has changed. That seems much
more likely to
eat ludicrous amounts of bandwidth to me....
b) a message to update task name, description and/or Detail (so that
values changed by the client are made known to the server).
Yes. An update message is definitely needed.
c) a message (or mechanism?) to change the set of valid task types.
A "mechanism" already exists. The set of valid task types is determined
by the server. It should be set up when the server is configured. If you want
to change what the current task server recognizes, then go ahead and
change it.
OK, I'll go hack the server source. However, I think that's a pretty
temporary solution.
Consider Bugzilla, which allows different projects to define their own sets of
Component tags. Presumably some kind of admin tool allows a project admin
to specify the component tags for a given project, without having to
rebuild the
Bugzilla server and run one Bugzilla server for each project .....
d) a message or other means for listing the task state maintained
by the task server. For each task known to the server, this
should include: taskID, task name, owner, reserved resource ids.
This, again, is a scalability issue. The client really doesn't need complete
information about every activity in the system. If you've got thousands of
activities (not an unreasonable possibility), you could be talking about
megabytes of data here. Why does the client need this?
Currently, it would be very useful for debug purposes (to compare client
state with server state when things don't match). For admin purposes,
I can imaging uses such as compiling a conflict history for a given resource,
as tasks come and go....). OTOH, things like conflict histories are better
generated by direct access to the underlying task database (the task server
shouldn't be expected to keep state around for completed tasks ...)
Adding a command to list tasks, with name and description, is reasonable.
Dumping the complete task server state to the client just doesn't make sense
to me. Why can't the client just query the server for the tasks that it's
interested
in?
A list tasks command would be sufficient; I can then query tasks of
interest by taskID.
At present, I can't easily find out what tasks the server thinks
exists. (And after multiple
debugging sessions across a number of days, the persistent task store can
get a bit
cluttered..... blowing away the server state file has been necessary
several times, but
seems dubious as a long-term strategy....)
e) a message or other means for listing the resource reservations
maintained by the server. For each resource known to the server,
this should include the <taskID,task name> for each task reserving
that resource. (I suppose one approach might be to simply parse
the XML the task server uses to persist its state...)
Again - why does the client need this? Why can't it just query the server
when it needs to know who's reserving a particular resource?
This (list resource reservations) was mostly for debugging.
However, the refresh_task_conflicts message discussed below would be
for regular client use as well.
Some changes w.r.t. retrieving resource-specific conflict info is probably
also needed. TaskServiceClient.getTasksReservingResource does not
return conflict id, conflict timestamp etc. -- just the taskID for every task
reserving a resource. De- and re-activating a task (to generate flood of
up-to-date conflict notifications) doesn't seem like a good idea, because
other team members might also get a flood of notifications.... not good.
Maybe a message 'refresh_task_conflicts', which sends an up-to-date
list of conflicts for a given task, but not to any of the associated tasks?
Thoughts?
You didn't comment on this message (refresh_task_conflicts), but I think
it's more important than the 'list resource reservations' suggestion.
Resource conflict information includes conflictID and a timestamp (when the
conflict occurred) as well as the relevant resource and task IDs.
However, there is currently _no way_ to get the conflictID and timestamp except
via the initial conflict notification message sent by the server.
For a number of reasons, discussed above, it seems necessary for the client
to refresh (and rebuild) conflict information at various points _after_ the
conflict
is initially reported. Since I can't get the complete conflict
information, I cannot
currently rebuild ResourceConflict items locally (or rather, when I do, the
PropertySheet view for a rebuilt ResourceConflict lists the value for conflict
timestamp as "Server Won't Tell Me". While the conflictID is not shown to the
use, we'll need it to retrieve chat transcripts and the like, and I won't
be able
to do that for locally-regenerated ResourceConflict items.
[Input! I need input! (or at least data)]
BTW, my current plan (for STIM) is to disable the Refresh Conflicts menu
item, package the current STIM in both source and update-site formats,
update the CVS source accordingly, post drops on svc.watson, make some
screenshots and update the Wiki text to include a very brief user guide.
That way we're reasonably ready for demos, and to integrate Stim with
the Stellation CM client, once we have a plan for that.
I wouldn't spend time on the update-site stuff. The code really isn't
stable/complete
enough for naive users - it's still really hacker-only. So I think source
drops is
plenty - and in fact, I think that updating the SVC copy is enough.
Who said anything about circulating Stim to 'naive users' ?
The internal update site is just to make sure you have access to both feature
and source drops.
IMHO, installable features are the best way to keep a stable demo version
around.
If I need to demo something, I just install the feature, restart Eclipse,
and I'm ready to
go. Not to mention: I use Stim daily to track my own development tasks and to
help manage open source editors in Eclipse. That would be pretty tough to
do if I
could only use Stim in debug mode....
Finally, I don't have to worry about demos getting screwed up by flaky
in-progress
code, by inconsistencies between source versions of different plugins, etc.
I can _always_ get a demo going by installing (or reverting) to a stable
packaged feature.
(and confidence-builders are a good thing when a demo is looming).
Post-finally: packaging the feature highlights any missing resources,
inconsistent
plugin manifests or other issues. I repackaged my current Stim drop
earlier today,
and found some dangling dependencies related to the recent Stellation changes
(stellation.core -> stellation.repos, creation of stellation.util). There
were also some
version number mismatches, which I've fixed (and will check in as soon as I
can).
This didn't take a whole lot of time -- maybe half an hour start-to-finish
-- and I'm
sure it will save me grief down the line.
I will also be checking changes into the Stell repo, of course, once I've
reconciled
the current Stell image with the Stim code. Per our previous exchanges, there
were various missing files and source changes which made it somewhat tricky
to make a working version rooted in the Stell repo image (I think it took me
a full day to work everything out last week, which would have trashed my
demo preparations if I'd done the Stell repo integration _before_ packaging
the Stim demo version). Since the Stell repo has been down for the past three
days, I'm going to have to reconcile various local changes with the current
Stell
repo image -- no big deal, but it may take a bit of time.
- Jim
--
Jim Wright, IBM T.J. Watson Research Center
*** The Stellation project: Advanced SCM for Collaboration
*** http://www.eclipse.org/stellation
*** Work Email: jwright@xxxxxxxxxxxxxx ------- Personal Email:
jim.wright@xxxxxxx
