Graphical user interface for Click

Brecht Vermeulen brecht.vermeulen at rug.ac.be
Fri May 25 13:02:35 EDT 2001


Eddie,

thanks for the flattering :-).

> > - some packaging problems : as CORBA is needed, there is need for a
> > CORBA implementation (it works with C++ omniORB/Orbacus/TAO and the Java
> > side needs Orbacus), so these are needed to compile and run the beast.
> > E.g. Orbacus is free software for educational use, but not for
> > commercial use (and the Java side uses Orbacus, however it should be
> > possible to port these to a free Java ORB, but this is not yet tried).
> > What would you propose about this ? There is also still some work to do
> > to package it up, so the release wouldn't be for tomorrow :-).
> 
> Honestly, I would suggest that you provide an alternative to CORBA, namely
> Click's existing ControlSocket. Don't throw away CORBA, of course -- let
> people choose which they want to use. But ControlSocket was written exactly
> to provide the functionality you're using CORBA for. Have you looked at the
> ClickController Java program we distribute with Click? It looks like it
> fell out of the latest tarball, but it is in anonymous CVS. Let us know
> what you think about this.
> 
> (ControlSocket communicates with a user-level Click. However, there are
> ways to use ControlSocket to communicate with a kernel Click.)
> 

Yeah, we've looked at ClickController Java program, but it's a pity it's
only 
for userlevel Click (well, our application only works for kernel Click,
as it is based on the 
/proc interface).

However, we've used CORBA to avoid the problems with low level (well,
kind of ;-) ) socket programming
and to speed up the development time. So, it's rather a lot of work to
develop a raw TCP/IP implementation
of the GUI. E.g. each element is represented as a different CORBA
object, and as such the JAVA GUI can ask 
the connected elements of an element to the C++ CORBA server via the
following IDL definitions :

  /**
   * Struct describing a connected element in detail
   *
   * @member name name of the connected element
   * @member port port of the connected element to which this element is
connected
   **/
  struct connected_element {
    string name;
    short port;
  };
 
  /**
   * Struct describing an input or output port in detail.
   *
   * @member processing_type describes the processing type of the port
(push or pull)
   * @member agnostic true, if the port is agnostic (which means that
the port processing type
   *                     is determined by the configuration)
   * @member connected_elements names and ports of the elements
connected to this port
   **/
  struct port_detail {
    processing_type_enum processing_type;
    boolean agnostic;
    sequence<connected_element> connected_elements;
  };
 
  /**
   * Struct describing the input and output ports of the element.
   * All information is contained in the sequence, e.g. the number of
ports (length of sequence),
   * the order (e.g. sequence[1] is the second port)
   *
   * @member inports describes the input ports of this element (length
of the seq. is the number of ports)
   * @member outports describes the output ports of this element
   **/
  struct ports {
    sequence<port_detail> inports;
    sequence<port_detail> outports;
  };

so, to provide this same information to the JAVA GUI, a lot of work has
to be done + the JAVA GUI has to do parsing of the information that
comes in via the TCP/IP socket.

We haven't actually the resources for this adaptation, so maybe it would
be a solution to put on a website a binary version of the application.
(the JAVA GUI is only 2 jar (JAVA archive) files, 1 with the GUI and 1
for the ORB of Orbacus and the C++ CORBA server could be provided in a
Linux package, e.g. we use Debian, so it would be a Debian package with
dependencies to ORB packages in Debian, e.g. omniORB or TAO).

As such, it would be possible for users, to just download the binaries
and start the application, while people wanting to compile the thing
would need a CORBA dev package.

Others could then maybe hack in a TCP/IP socket communication.

What do you think of this ?

best regards,
brecht



More information about the click mailing list