[sword-devel] Creating a "SWORD-over-network" protocol for remote SWORD repo access?

[Aaron Rainbolt]

On 7/13/24 11:18, Aaron Rainbolt wrote:
> On 7/13/24 03:11, Peter von Kaehne wrote:
>> You can ask for parts via the study application . I do not think anyone has yet 
>> decided to build an app around that. But I see no reason why not. It probably 
>> needs dusting off and some further work to make more universally useful, but it 
>> is uo and running and always available.
> I think by "the study application" you probably mean SWORDWeb?
>
> I briefly glanced at some of the code. It looks like it's doing more or less what I imagined - one computer calls SWORD methods that access module information on another computer. It seems to be using CORBA for this.
>
> I can see some advantages here:
>
> * The protocol already exists and works in active use, which is a huge bonus.
> * The server already exists and is short, simple, and already a part of SWORD itself.
> * Since it's part of SWORD, all of the library support work has already been done.
> * Now we just need people to stand up servers and get clients to use it!
>
> But... therein lies the sticky part. How to use this?
>
> I don't really like that the system uses CORBA because it means that any dev who wanted to implement network support in their SWORD frontend would have to add dependencies for CORBA support, and then potentially restructure their code to create and use CORBA objects rather than normal SWORD objects when using SWORD over the network. That would require a potentially significant amount of effort since now every single place in the application that uses SWORD objects has to do something like "if ( usingNetwork ) { mgr = makeCorbaSwordMgr(); } else { mgr = makeNormalSwordMgr(); }" or something similar. The complexity this would introduce could potentially be very significant and result in low adoption of the feature (i.e., this may be why SWORDWeb is the only thing that uses this). Then you have to add on error handling considerations in the event of a network failure (something which clients would have to do themselves rather than SWORD being able to do for them), which adds
> another layer of complexity.
>
> As for the server side of things, proxying is no longer something that can be done by just chaining servers. You'd have to have a real proxy server using a protocol like SOCKS5 or something rather than just having a SWORD server that used another SWORD server as its backend.
>
> Some of the above problems I guess could be solved by writing support for accessing modules over CORBA directly into the SWORD library. It wouldn't solve the proxying issue, and it wouldn't solve the need for an extra build dependency, but it might solve the complexity problems for clients. Not sure how practical or efficient this would be, but it could work.
I dug into this more and I'm not so sure this will work after all. It turns out that CORBA isn't used for the SWORDWeb client to communicate with the server's SWORD repo like I thought. Instead the SWORDWeb server appears to use CORBA as a kind of Java-to-C++ compatibility layer, allowing it to retrieve SWORD data from its local repository and render it remotely before sending it to the client for viewing. The client only ever sees the website AFAICT, not the SWORD module data. (N.B.: I didn't dig into the code too deeply, I just skimmed parts that looked relevant.)

I also tried to familiarize myself with what CORBA was and how it worked a bit more, and also managed to build and run swordorbserver and its corresponding testclient. It seems like it would need a significant amount of effort to make the existing swordorbserver implementation secure from a malicious client, as well as to encrypt the connection between client and server. For SWORDWeb this doesn't seem to be a concern since swordorbserver is (apparently?) just being used as a backend, and isn't exposed to the public.

Even if this existing implementation was made suitable for exposing to the public, there are things about how CORBA works (in particular with establishing a communication channel via an IOR) that makes me thing it isn't ideal for a general-purpose SWORD server. Still, it was interesting to look into, and I learned a lot.