[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
AW: AW: [geclipse-dev] Separating geclise grid model from eclipseworkspace
|
> I think this is a shame.
Let's see ...
> Your model is well designed (high abstraction
> level) and you provide several implementations of it. It is a dream
for
> whoever wants to implement applications that at some point should
submit
> jobs to a distributed environment.
Hey team, we should invite this guy to our next project review ;-)
> Having a tight link to the eclipse
> workspace here is painful when you just want to benefit from the
> abstraction layer of geclipse within your own tools. For example we
have
> an information system. It is able to store many information about our
> application for traceability purposes. I want it to store the jobs
with
> a description, the id, the wms url.... for further use, but as long as
> IGridJobs and IJobDescription are linked with workspace objects seems
> pretty complicated.
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?! 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
;-)
> Actually I don't really need it. It is possible to disable it within
the
> current context?
Not as far as I can see. Just had a second look and GridJob is really
tightly bound to the workspace.
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? 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?!
Cheers, Mathias
