[Pipet Devel] thoughts on UI->DL communication

jarl van katwijk jarl at casema.net
Tue Apr 11 14:27:31 EDT 2000


> Brad, Jarl and I were all talking about UI->DL communication over chat.  I
> want to summarize my own thoughts.
>
> First, the VSH plan for the UI->DL parts and the communication between them,
> is to re-use Loci's Front->Middle parts and communication.  So,
>
>      VSH            Loci
>     ------         ------
>     UI->DL  ==  Front->Middle
>
> But Loci's Front->Middle parts and communication are also very similar in
> design to VSH's DL->BL parts and communication.  Both Front->Middle and
> DL->BL...
>
>     * Act like client->server
>     * Pass XML
>     * Need authentication to connect
>     * Can connect across a network
>
> So, I see a lot of duplication between UI->DL and DL->BL in the current plan
> that need not be there.
>
> Jarl suggested that VSH use 1 UI per DL.  This makes DL a client rather than a
> server and eliminates much of the duplication mentioned above.
>

Not really, I've been my lungs out, lot, and came up with this:
-Make the dl be a 'wrapper' for UI's, not an extension.
I'm saying this: let the DL make programming new UI's easy.

Various scripting and new GUI can be developped fast that way. I dont know WHAT
 the DL should be doing, that's probably a question that Brad can answer best,
but
programming the BL corba and implementing the DL api every time again when
somebody makes an UI\DL (read: single application) seems like a dull thing to do.

And there will be numberous features to code that will make the DL a nice part of

the VSH project.


>     (1) Speed: Direct Python communication rather than socket
>     (2) Less processes running: 1 processes rather than 2
>     (3) Unified code base
>     (4) One less authentication system needed (recall we would need 3)
>     (5) Elimination of sockets: keep corba as the only protocol
>     (6) No XML management (reading and writing) between the two

Good points you brought up here Jeff, but not as good as mine :-)
About (4), we'll only need 2 authentication systems, the UI wont log into the DL,

it will link\fork it, the DL will log into the BL or another DL. If this login
does not
succeed both the UI\DL will be rejected.
Maybe Brad and you can figure someting out that 'fixes' (5) & (6), if  needed. I
dont see (1), (2) and (3) as big problems.

>
>     (1) There would be a lot of rewriting to do, which would make Brad
>         very unhappy.

We definitly wont have that, I cant stand blood :)

>
> I'm not suggesting that we re-integrate the two parts.  I think the separation
> is good, because the use of the UI as a library would require a separate
> anyway.  And as far as work goes, I can do it myself.

Library, sounds good

>
>
>     (2) Other UI's would have to be made in Python.

They have to? There's no way the DL code can be compiled as binairy??
(Python -> C -> binairy)
Stick to the sockets otherwise.

>     (a) The whole UI->DL part can be written in another language
>         and use CORBA to communicate with the BL.

Aaiiks.
The result would be very nice though.

>
>     (b) Write a UI part in Python that can communicate with non-Python
>         UI's, using a language-neutral protocol like CORBA.

Nah.. please dont! Use corba for UI->DL communication instead if sockets aint
good enough.


bye,
jarl





More information about the Pipet-Devel mailing list