Re: AW: [geclipse-dev] Replicable File Systems -proposal tothe corechang

[Mateusz Pabis' <uranium@xxxxxxxxxxxxx>]

Hi Mathias et al.

> I think most points turned already out to be agreed by everybody,
> i.e. hiding complexity, supporting also pros etc ... So I will focus
> on the remaining questions, i.e.
>
> 1) Should we have an abstraction layer for replicated file systems as
> part of the core? 2) Is a dedicated view for such file systems
> needed?
>
> So let's come to 1) ... I am a fan of abstraction, you might already
> know this ;-) Nevertheless the question is always if it is worth
> having an abstraction. So what are the pros and cons (that I can
> think of)?
>
> Pros: - We could have a standardised UI for replica file systems 
> - Others could profit from the abstraction
> Cons: - We would loose our compatibility with EFS

I don't agree. The support I recommend is optional. Proposed extension 
is already in EFS style (and only 2 methods added to filesystem, and 5-6 
to filestore). In the maximum plan we would introduce it to the eclipse 
core. It's more like: canWrite(), canDelete(), isCaseSensitive()... 
there will be isReplicable()

The replica interface methods will be used internally in the 
ReplicableStore, so no harm if any one would like to reuse our code.

> Nevertheless, if the abstraction would be well designed I would
> rather tend to agree to such an extension. If we decided to go for
> such an extension we definitely should talk about the technical
> details once again!

Let's start it then.

> Now the 2nd point: I definitely do not like the idea of having
> another view! For me the properties view would definitely be the view
> to reuse here. I like Harald's proposal regarding the structure how
> things should be shown there. Nevertheless the properties view is
> rather thought to be a passive view, right? It only shows information
> but does not offer any functionality, at least as far as I know.
> Please correct me if I am wrong. So that would mean we would have to
> add all actions to the project tree, which is also nice as I think
> (at least if we solve the problem with hiding actions that are not
> applicable to a specific selection). These actions would then have to
> trigger secondary UI elements (Wizards and Dialogs) supporting the
> user with doing what he wants to do (e.g. delete replica -> wizard
> opens with a list of replicas to be chosen -> OK deletes all selected
> replicas).

Yes, properties view is somehow limited. You can edit the property, but 
as a string only, so not very usable with dealing with replicas.
But there is a property dialogue. I'll investigate it.

> So to summarise: Abstraction Layer as part of the core: +1 Yet
> another view: -1 Make use of the properties view: +1 Add actions to
> project tree: +1

Ok, no more views :-)

> BTW, of course we make use of the ProblemException! Everybody can
> reuse the code with the ProblemExceptions, it is just one very small
> plug-in that provides this functionality.

Since ProblemException extends CoreException, why don't use 
CoreException in the interface definition and ProblemException in the 
implementation? It's how we do it right now with IFileStore.

--
Mateusz