Re: [geclipse-dev] GRIA data managmement

[Ariel Garcia <garcia@xxxxxxxxxx>]

> > We download a whole bunch of extra info for each data stager
> > each time we expand a connection: i mean the
> >       "getting information for $FILENAME"
> > part. At the moment we already have the filenames, and we
> > could already display the folder contents! (for that we only
> > need the name, ie the "label")
> >
> > The info of each stager can be fetched lazyly later if the
> > user opens the properties view for instance. This should make
> > the gria connections much more agile.  Listing a folder is
> > usually a ~O(1) operation, looping over files is obviously
> > O(N)... :-( Or is there anything preventing us from doing it this way?
>
> I would also like to see more data cached on the client, so that
> we can quickly expand/collapse connections.
>
> Compare current implementation with GRIA client, which lists all
> of the services and resources, as per the cached EPRs in the
> client.state
> file (i.e. the FileStateRepository). Updates are only fetched on
> request by the user, e.g. discover resources, update EPR, check job,
> etc.

i didn't say i wanted caching ;-)
Not that it wouldn't be an option, but as Mathias remarks it has some 
associated problems, and at some point we also removed caching from the 
info system.

What is important for me is that we keep a unified behaviour and user 
experience across different middlewares. It would be confusing/bad to have 
GRIA caching the info and glite not etc.

In any case, i as a user would rather prefer to avoid having to 
refresh/reload the information myself, at least if the queries are fast 
enough.

> > On the other hand, if i understood the code correctly there
> > is another "remote" operation per file needed for each
> >        "processing $FILE"
> > step, in which we get the stager labels. I guess that is
> > unavoidable (the cost of userfriendliness) with the current
> > GRIA API right?
>
> Didn't quite understand that bit, but if you or someone else could
> clarify what calls are made?

Mariusz clarified (and improved) that part already :-)

> Could be a useful feature, though might be hard to implement.
> Not sure if you can query a resource to say who is the owner, for
> example.
> For non-owned resources, this would generally result in a failure
> message,
> indicating that you don't have permission to read the access rules!
> (unless you could somehow use this information).

sure. There is also a 
   boolean checkWriteAccess(SubjectDescription delegateUser)
method  (which throws exception instead of "false" in some cases as Szymon 
discovered ;-)
but any of those queries would be again O(N)... so perhaps we just forget 
that and let the edit/save/etc operations handle the exceptions informing 
the users of the permission problem (as happens in the OS anyways, except 
for the permission bits in the filemanager you might not notice the file 
is readonly until you try to save it in an editor...)


> I agree that when many users give access to his data stagers to others
> users, then user will have a lot of data stagers on his list and most of
> them will not be interesting for him.

it is true that when we do _test_ it is somehow silly (because many of us 
create lots of small "test" files etc)
but in a true "production" environment each "scientist" tends to know which 
files are his input data (which he needs to edit), which are outputs 
generated by him or by others (and usually not changed anyway)
So perhaps it is not that important as usecase and we can "handle the 
exceptions" if the user tries the forbidden op.

> Maybe we should create subfolder "Other stagers" to have 2 lists: my
> stagers and other's stagers? Or better: many subfolders each for every
> foreign user.
>
> Fundamental question is: do we have possibility to filter my data
> stagers and others? How efficient is it?

efficient most probably not, one call per stager. In any case AFAIK in GRIA 
usually you cannot know the owner (if it is you, then of course yes ;-)
you have   checkWriteAccess( user ), and getValidRoles()   to try to see if 
you are allowed to modify the file... (and then of course fetch the whole 
ACL)

Cheers, Ariel