[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
AW: [geclipse-dev] GRIA data managmement
|
Ariel, Ken,
Please be very careful with all these cachings! In terms of the UI g-Eclipse you are absolutely right but g-Eclipse is not only a UI, it is also an API used by other developers to write their applications with. We already had problems with such external applications because the fetchInfo stuff was not implemented properly!
Cheers, Mathias
-----Ursprüngliche Nachricht-----
Von: geclipse-dev-bounces@xxxxxxxxxxx im Auftrag von Ken Meacham
Gesendet: Do 07.08.2008 17:31
An: Developer mailing list
Betreff: RE: [geclipse-dev] GRIA data managmement
Hi Ariel,
> currently "expanding" a GRIA connection is not very performant.
I certainly agree with that! It can be quite frustrating at times...
> 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.
> 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?
> On the other hand, a feature which would be really useful i
> think is having different icons for owned stagers compared to
> stagers we can see/read but do not own... this would be a
> nice improvement for the not-so-rare ;-) use case of trying
> to edit shared files.
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).
Nevertheless, I agree that it would sometimes be nice to be able to
distinguish between data stagers that I have created and those that
someone else has created, but I have read (or other) access to.
Similarly, some time ago we had some discussion about annotating
data stagers to show if they were full or empty. What happened about
this?
As its a related issue...
Regards,
Ken.
_______________________________________________
geclipse-dev mailing list
geclipse-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/geclipse-dev
