411573 - Update OS/2's README.txt with information on RWS

Status: RESOLVED FIXED

(Core :: General, defect)

Description

[Peter Weilbacher]

Now that RWS support is in we need to document how to (de-)activate it and what it does.

Comment 1

[Peter Weilbacher]

This is the text that I now added in README.txt for the 3.0beta3 release. It sounds somewhat clumsy to me, perhaps you can help me to clean it up in time for the next beta? Perhaps I missed something?

Support for WPS objects in the browser
--------------------------------------

Firefox can make use of Rich Walsh's Remote Workplace Server (RWS) library to
access objects on the Workplace Shell from the browser. This means that helper
applications can be selected for downloaded files depending on their default
WPS association. It will also display the WPS icons of files in the download
dialog and in directory views.

To enable this functionality, get RWS from
   http://hobbes.nmsu.edu/cgi-bin/h-search?key=rws08
and unpack it somewhere so that Firefox can find its DLLs (put them into a
directory on the LIBPATH or copy them into the Firefox directory).

Comment 2

[Steve Wendt]

My suggestion:

Firefox can make use of Rich Walsh's Remote Workplace Server (RWS) library to
access Workplace Shell objects from the browser. This allows helper applications for downloaded files to be selected based on their default WPS association. In addition, the WPS icons of files will be displayed in the download dialog and in directory views.

---

1) directory views = XUL view? or is that different in trunk?
2) if RWS becomes tri-licensed, can the binaries just be included in the build?
3) I think you still need to mention how to (de)activate it via the script?

Comment 3

[Peter Weilbacher]

Thanks for the correction, just in time to include in beta3. :-)

ad 1 No, you don't need XUL view any more. It still works in SeaMonkey
     but the standard view is even nicer (I think) and has all the icons,
     too.

ad 2 The packaging system isn't really suited well to draw in external
     files (although I use an ugly hack to do that for PmW-*). If we
     would build RWS in the tree then I would say it's possible but that
     doesn't make much sense to me.

ad 3 Yes, perhaps something like this

     If RWS is found on the system, it is used by Firefox automatically.
     In case you want to remove RWS support, use the RWS08.CMD script
     included in the RWS distribution to deregister the WPS class and
     delete RWS*.DLL from LIBPATH.

Comment 4

[Steve Wendt]

(In reply to comment #3)
> ad 1 No, you don't need XUL view any more. It still works in SeaMonkey
>      but the standard view is even nicer (I think) and has all the icons,

Maybe XUL view will end up getting removed; I found its drawbacks (no context menus, no navigation to parent) to be greater than its advantages.

>      If RWS is found on the system, it is used by Firefox automatically.
>      In case you want to remove RWS support, use the RWS08.CMD script
>      included in the RWS distribution to deregister the WPS class and
>      delete RWS*.DLL from LIBPATH.

The latter bit is because it auto-registers itself if the DLL loads?  Should that be mentioned, or is that covered well enough in the RWS docs?

Comment 5

[Rich Walsh]

(In reply to comment #3)
>> if RWS becomes tri-licensed, can the binaries just be included in the build?
>  The packaging system isn't really suited well to draw in external files

Too bad - I'd certainly prefer that over "here's yet-another-package you need".

BTW... speaking of yet-another-package:  any chance of getting rws.h in the tree to avoid yet-another-dependency?

>  If we would build RWS in the tree then I would say it's possible but that
>  doesn't make much sense to me.

It can't/shouldn't be built with gcc.  It was designed to use VAC 3.65's subsystem (device-driver) library.  Because it has no runtime environment (i.e. it owns no memory, needs no initialization, etc.), it will never conflict with other C runtimes in the same process - most notably, in the WPS.

>> I think you still need to mention how to (de)activate it via the script?
>  Yes, perhaps something like this
>      [...] 
>      In case you want to remove RWS support, use the RWS08.CMD script
>      included in the RWS distribution to deregister the WPS class and
>      delete RWS*.DLL from LIBPATH.

This is something I was just thinking about.  The steps you suggest aren't sufficient.  If you run another app that uses RWS, mozapps will once again find & use it.

What I want to do is define an environment variable %MOZ_NORWS% and test for it in nsRwsService's constructor.  If it exists (the value doesn't matter), the constructor will return NS_ERROR_NOT_AVAILABLE.

I don't think a user will ever _need_ this but I wouldn't feel comfortable knowing it wasn't there.  Once I have some code ready (about 3 lines?), I'll file a new bug.

Comment 6

[Rich Walsh]

(In reply to comment #4)

> The latter bit is because it auto-registers itself if the DLL loads?  Should
> that be mentioned, or is that covered well enough in the RWS docs?

RWS docs?  Not exactly...  The package I put on hobbes (rws080.zip) includes a bunch of apps and their docs describe how to handle RWS08, but there's no stand-alone RWS08 doc.  In any case, that zip contains far more than the moz-user needs.  I'm going to package the dlls, rws08.cmd, and some basic info in their own zip and call it "rws080dll.zip".  When I have a URL, I'll post it here.

BTW... I created the patch to disable RWS:  it's Bug 417372

Comment 7

[Peter Weilbacher]

(In reply to comment #5)
> (In reply to comment #3)
> >> if RWS becomes tri-licensed, can the binaries just be included in the build?
> >  The packaging system isn't really suited well to draw in external files
> 
> Too bad - I'd certainly prefer that over "here's yet-another-package you need".

It's not nice but as long as we don't really depend on it... Isn't RWS getting shipped with eCS?

> BTW... speaking of yet-another-package:  any chance of getting rws.h in the
> tree to avoid yet-another-dependency?

If you could attach a tri-licensed version of rws.h to bug 411578 that could help.

Comment 8

[Peter Weilbacher]

Rich, I haven't found that rws08dll package on Hobbes. And I think it's not actually necessary. The instructions are easy enough to follow if somebody cares about this feature, and when we have MOZ_NO_RWS I don't think we need anything else, not even the .CMD (at least not for the Mozilla apps).

Still haven't found out if RWS is shipped with eCS...

Comment 9

[Peter Weilbacher]

Attachment: patch for readme

OK, so once the patch for bug 417372 is in, I would like to apply it like this.
Steve, Rich, are you happy with this?

Comment 10

[Steve Wendt]

> +- set MOZ_NO_RWS=1
> +  Use this to run disable WPS support (see below).

-> Use this to disable Remote Workplace Server support (see below).

The rest looks good to me, although it doesn't say what Doodle's Screen Saver is used for, or where to get it, as it promises to do at the top.

Comment 11

[Steve Wendt]

(In reply to comment #10)
> it doesn't say what Doodle's Screen Saver
> is used for, or where to get it, as it promises to do at the top.

I see this is in the other patch, though:
https://bugzilla.mozilla.org/attachment.cgi?id=308238

Comment 12

[Rich Walsh]

(In reply to comment #8)

> Rich, I haven't found that rws08dll package on Hobbes.

I just put it there (I'm slow).  It's rws08dll.zip

> And I think it's not actually necessary.  The instructions are easy enough
> to follow

Who wants to deal with a bunch of junk they don't need or understand?

> Still haven't found out if RWS is shipped with eCS...

It was in rc4.  I don't know if it was because they included 'oo' or because they used your build of FX.  I wouldn't rely on it, though.

Comment 13

[Peter Weilbacher]

(In reply to comment #11)
> (In reply to comment #10)
> > it doesn't say what Doodle's Screen Saver
> > is used for, or where to get it, as it promises to do at the top.
> 
> I see this is in the other patch, though:
> https://bugzilla.mozilla.org/attachment.cgi?id=308238

Yes, sorry. It's a bit difficult to disentangle two patches of the same file...


(In reply to comment #12)
> Who wants to deal with a bunch of junk they don't need or understand?
> 
> > Still haven't found out if RWS is shipped with eCS...
> 
> It was in rc4.  I don't know if it was because they included 'oo' or because
> they used your build of FX.  I wouldn't rely on it, though.

Because the DLLs might otherwise already be installed, I think the text should read somewhat like this:

   To enable this functionality, Firefox has to find the RWS DLLs. They
   have to be located in a directory on the LIBPATH, in the Firefox
   directory, or already be registered as a WPS class. If RWS is not yet
   available on your system, download it from
      http://hobbes.nmsu.edu/cgi-bin/h-search?key=rws08dll

   If RWS is found on the system, it is used by Firefox automatically.
   In case you need to disable RWS support, create an environment variable
   MOZ_NO_RWS and set it to 1.

I asked Joachim for confirmation, if they will be in eCS 2, then one could point that out here.

Comment 14

[Peter Weilbacher]

Yes, I got confirmation that the DLLs will always be installed for OO in eCS 2. So perhaps this should be:

   To enable this functionality, Firefox has to find the RWS DLLs. They
   have to be located in a directory on the LIBPATH, in the Firefox
   directory, or already be registered as a WPS class. For eComStation 2
   this is already the case. If RWS is not yet available on your system,
   download it from
      http://hobbes.nmsu.edu/cgi-bin/h-search?key=rws08dll

Somehow the above still sounds too convoluted...

Comment 15

[Peter Weilbacher]

I can think about phrasing forever and in the end nobody is going to read that file anyway. So I checked in the changes now. If someone doesn't like it as it will come in FF 3beta4 or the next nightly then please reopen.