[prev in list] [next in list] [prev in thread] [next in thread] 

List:       slide-dev
Subject:    Re: Proposal for adding DeltaV support to Slide [more readable no w]
From:       Christopher Lenz <cmlenz () gmx ! de>
Date:       2002-01-28 14:42:44
[Download RAW message or body]

Hi Peter,

28.01.2002 11:05:58, "Nevermann, Dr., Peter" 
<Peter.Nevermann@softwareag.com> wrote:
[...]
>> Now I *personally* do think that the core API *could* be changed to 
>> enable such functionality directly. This would be a huge change, 
>> but maybe we should consider identifying nodes by a UID, and making 
>> the URI a property of the revision. I haven't thought this through, 
>> just trying to trigger a discussion.
>
>Since such a more "revolutionary" approach would have a major impact
>on the store API (as Remy pointed out), we opted for keeping things 
>stable for now. But, changing the core API may be justifiable at any 
>point of time ... I am curious about the discussion.

Yeah, I thought the implications on the store API would probably be 
quite large. But what I'd like to see would be some kind of quick 
overview of how much the Slide kernel would need to change to support 
the DeltaV model more naturally. Note that I am not opposed to the 
implementation you proposed, as it obvious has strong benefits for 
API-stability and development time.

I really need to do my homework reading the DeltaV specification soon 
:)

>> - Could we put the workspaces directly into the user nodes, i.e. 
>> have "/users/john/workspace/a" instead of "/workspaces/john/a" ? 
>> (I'll have to catch up on the whole concept of workspaces I think 
>> :P)
>
>No, because we probably would get a conflict with the semantics of 
>the /users tree. The URI "/users/john/workspace/a" could mean that 
>"john" is a group, "workspace" a subgroup of "john" an "a" a 
>principal in the group "/users/john/workspace".

Hmm, what makes "/users/john/workspace" different from the hypothical 
"/users/john/My Files" ? A principal-collection is identified by it's 
type, which must be GroupNode. The node "/users/john" is a SubjectNode 
(with user-role), so I can't see a potential conflict here. Putting 
the workspace into the user 'directory' seems cleaner as it is user-
specific anyway, and you don't have to replicate the complete user 
list in another scope.

OTOH, as the user node can also serve as sort of a home directory, the 
workspace would be directly exposed to the user over WebDAV. I don't 
know if that's a problem, i.e. if users should only be able to access 
their workspace indirectly through versioning methods.(?)

I guess it *may* be a problem if you want to map the scope for 
workspaces to a different store, but then I'd rather see the scope-
mapping flexibility improved (or removed ?).

>> - Clients: what are you using to test the DeltaV implementation, 
>> the Slide CLI client ? 
>
>Yes. The extensions for DeltaV are already commited in Slide client.

Cool :)

-chris
________________________________________________________________
cmlenz at gmx.de




--
To unsubscribe, e-mail:   <mailto:slide-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:slide-dev-help@jakarta.apache.org>

[prev in list] [next in list] [prev in thread] [next in thread]