Re: [dsdp-tm-dev] Re: RSE server (dstore) packaging

["Patrick Tassé" <patrick.tasse@xxxxxxxxx>]

Hi Martin,

 

* We build the rseserver-*.tar archives as part of our
  nightly releaese engineering process, see the
  org.eclipse.rse.build project (shortly to be replaced
  by org.eclipse.tm.build)

 

Oh, found it now, I had previously only imported rse-anonymous.psf into my workspace. Needed rse-releng-anonymous.psf...

 

Did you consider TCF or SSH on the server side? Why do
you think you'd want dstore?

 

I hadn't considered them, I had misunderstood that dstore was the only way to go if I wanted to reuse RSE's process and file subsystems. Now I see that each subsytem/service can use multiple protocols.

 

But after looking more into it to answer your question, I feel that a dstore server in Java on the remote host would be easier for me to port to a new platform, and to be inspired by the process/file implementations for the new subsystem functionality. But I could be wrong...

 

From: David McKnight

Regarding downgrading the dstore server code to 1.3, if you set the compiler compliance level to 1.3, the dstore.core, dstore,extra and miners seem to compile fine.  

There are a couple problems though:
1)  The JDK didn't add their SSL support until 1.4 - so it requires extra packages and the dstore code would have to change as a result.  
2) The JDK didn't add their regex support until 1.4  -  so again there are extra packages

It seems like changing the project's Execution Environment is more restrictive than changing the Compiler compliance level, it flags the SSL usages as errors.

Anyways I'm not sure yet if 1.3 compliance will be a requirement for my project, I was just wondering if it would be a showstopper.