Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: AW: AW: [geclipse-dev] Separating geclise grid model from eclipseworkspace
Hey team, we should invite this guy to our next project review ;-) 
Actually, I mean it !  8-)


Wait, this actually is the point of using the workspace. As you are
describing there is of course the need to write things in files, i.e.
the job ID etc., just to later on refer to it, right?!
In fact I was thinking the possibility to use the jobs, jobid and job descriptions as simple java objects not linked form their serialized representation within an IFile or whatever. Serializing those objects is one possibility (from my point of view) as using them without.
Jsdl description is a model of a job description in xml. Starting from that it is possible to conceive a java class that implements this model. Afterwards this model might be transformed by serialization in jdl, jsdl, pbs or so.
For example in this method of jsdldescription, why don't you get rid of the xml representation the jsdl using a java object containing the PosixApplication? 

 protected POSIXApplicationType getPosixApplication() {
   POSIXApplicationType result = null;
   DocumentRoot dRoot = getDocumentRoot();
   if( getJobDescription( dRoot ) != null
       && getJobDescription( dRoot ).getApplication() != null )
   {
// dRoot.getJobDefinition().getJobDescription().getApplication().getAny().get( 
     // eClass.getEStructuralFeature( "pOSIXApplication" ), true );
FeatureMap anyMap = getJobDescription( dRoot ).getApplication().getAny(); 
     for( int i = 0; i < anyMap.size(); i++ ) {
       if( anyMap.getValue( i ) instanceof POSIXApplicationTypeImpl ) {
         result = ( POSIXApplicationTypeImpl )anyMap.getValue( i );
       }
     }
   }
   return result;
 }
In a second time when you realy need the jsdl the entire object is serialized to it's xml jsdl representation. 
So all you have
to do is to set up the workspace once at the beginning (including the
project), everything else will be handled by g-Eclipse afterwards. The
GridJob in fact backs up all information in the workspace. When shutting
down your application and starting it up again the model parses the
workspace and restores everything for you. Even the job updaters start
up, catch the job IDs and immediately try to update the job's status. So
there is no need to back up anything by yourself here! Isn't that great
;-)
Yes it is, but that's the point here we want to backup things somewhere else (in an information system) not in an eclipse workspace. 
Not as far as I can see. Just had a second look and GridJob is really
tightly bound to the workspace.

Ok.

Nevertheless, as far as I can see from your mails, the actual problem is
not the workspace but the overhead of creating and managing it, right?
What if this creation and management could be reduced to a minimum?
Would you then be happy with all the advantages you get from the
workspace? Let's say you would have a method like

initThisFuckingGeclipseWorkspaceForMe();

that you could call at the very beginning of your application? Would
that be a nice-2-have for you?
Yes it would be nice if there is no other way (especially with this method name :)), because I think the problem still remains. 

A use case, to try to illustrate my point:
The application we are implementing is called SimExplorer and aims to distribute simulation transparently from the user point of view.
The user launches SimExplorer for distributing a simulation from it's desktop. He launches a simulation distribution. He stores anything possible in the distant information system database (a service of SimExplorer). Afterwards, he starts the application from another computer, he tries to retrieve the distributed application that is being executed, but some objects refers to a local workspace (something that is hard to put in the information system database).
The solution might be to reconstruct a workspace from the information system. But I think it is a pain in the ass. 
Maybe we should rather consider to make
the workspace handling for developers like you more easy instead of
thinking how to decouple the model from the workspace which in fact is
much more complicated?!
That might be a good idea. But I think that making the workspace management optional, would be the best solution. That way we might use our already implemented persistence API on g-Eclipse objects. 

Cheers,
Romain.

Back to the top