AW: AW: [geclipse-dev] Storage vs. Service

["Stuempert, Mathias IWR" <mathias.stuempert@xxxxxxxxxx>]

Hi All,

> we have tree different things here:
>    - how things are organized in the glue schema 

Which is also how things are organised in the Glue Info View ...

>    - how things are in our model

Which is how things are stored on disk + the virtual things ...

>    - how things are displayed

Which is how it seems to be most user-friendly (at least from our point of view).

> We should try to keep them more or less in sync, otherwise our code gets 
> completely messy!!!

Nope, they were never really in sync. Every structure has its dedicated purpose (see above) and is therefore organised in a special way. Parts of the structures are synced, but this is rather a side effect than a concept.

> So i would propose that the VO view follows the information in the 
> infosystem more or less closely.

I agree to the "more or less" ;-) As long as it makes sense (well I think it makes sense in any case) AND is user-friendly (which does definitely not hold for the data access services since I - as a dumb user - would prefer to have all "mountables" in one folder) I agree to follow the infosystem, i.e. GLUE.

> It is then of course responsabillity of 
> the <middleware>.info plugins to arrange the different 
> servers/services/resources into the information tree (glue schema in 
> principle)

Sorry, but here you are wrong. It is definitely the core's responsibility to group resources in the info/VO tree! If it would be the middleware's responsibility we would loose the common interface to all middlewares! Nevertheless the middleware of course has some influence on that (which interfaces do I implement for which middleware resource).

> where the Type is simply taken from Glue?  (ie, the glite.info plugin
> could 
> take care of reading the GlueServiceType published by the service, and 
> convert it into a human readable category,
>
>   GlueServiceType: org.glite.wms.WMProxy -> Type="Job SubmissionServices"
>   GlueServiceType: lcg-local-file-catalog       -> Type="File Catalogs"

This is completely middleware-dependent! So no way!

> well, just for the "mount" action it behaves like the SRMs, but for the 
> user (glite ones at least...) it is confusing

Please do not think too much about the gLite users. gLite is only our first exemplary implementation. And furthermore as I again saw at the user forum our users are most often not really familiar with gLite. They do know nothing about a SRM service. But on the other hand they love the mount action. So why not providing shortcut-access to the data access services by showing them as mountable storages. Once we decided to call it storage rather than SE in order to make it as general as possible. I know that LFC is a catalogue, but the ordinary user does recognise it as storage (which is in fact somehow the purpose why LFC was developed, to give the user easy access to storage by providing "virtual storage nodes/folders", right?!)

> uh? i mean, just for making LFCs appear in another part of the VO tree?

We did something for GRIA which is even more ugly, making the data service both a service AND storage ;-) But it works, looks nice and is user-friendly :) 

> yes, but not deeper as 3 levels please (3 clicks: VO, type, subtype)

Which is why we need it in storage ;-)

> To make more clear my point: we do not need to introduce extra (empty) 
> Interfaces  in the model just for being able to do 
>    if ( object instance of IMyCoolService ) {
>       //
>    }

Here I agree to Ariel. But the IGridDataAccessService would have (useful) functionality, so this does not hold.

> no, please no more things in the model... these are just re-combinations 
> of 
> available functionality

We want to build a middleware independent model, right? That means to have an abstraction layer that gives us the possibility to map middleware functionalities to our model. We furthermore promised to extend our model if needed. So in fact I do not see why we should not introduce such an interface. I know "Mathias, the model is already to complicated", can't hear it any more ;-) Of course it is - or do you think it is easy to potentially map all existing middlewares to one abstraction layer :-P

> i never understood why IGridJob 
> is an IGridResource... i am missing something for sure).

The original meaning of IGridResource was that Grid resources are non-local entities. Since a job is running on the Grid it is non-local. I know, it does not make too much sense and I personally have no string opinion on making it a Grid resource or not.

> So we _could_ have getServiceType (returning the GlueServiceType as said 
> above) in IGridService interface. But not inside a subinterface!

Ok, a point for you Ariel :) maybe we can find an easier way of grouping resources. Maybe we could have something like

public ResourceType getType();

within IGridResource. The ResourceType could be a class of concatenated subtypes like for instance

storage
storage.srm
computing
computing.cream
service.info
service.job.submission
service.job.status
service.data.srm

And maybe we should then think about what really is an IGridResource.
 
Just brain-storming ;-)

> Eclipse compliant or not... if you compare the Grid Project View with
> several other views (e.g. Package Explorer, Project Explorer), you'll see > that there
> *is* filtering available, but I've never seen dynamic filters à la 'search > as you type'.
> So in my opinion it is a nice feature, but *if* it is introduced somewhere > it should be introduced in a more general way, i.e. on an Eclipse platform > level.

Well, do you mean implementing it directly in org.eclipse.*?

Cheers, Mathias