axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [jira] Commented: (AXISCPP-210) Add back in C support in 1.5
Date Tue, 19 Oct 2004 14:36:51 GMT
The following comment has been added to this issue:

     Author: Mark Whitlock
    Created: Tue, 19 Oct 2004 7:36 AM
Tasks to add back in C support include work on the dynamic client API, the generated stubs
and services. Handlers written in C are not supported.

The dynamic client API will consist of external C header files and internal source files,
built into a new library, which C applications can link against. The C header files will be
.h files, whereas the C++ header files will be .hpp files of the same name. The C dynamic
client API will consist of global C functions. All externalised functions will be prefixed
with axis. Externalised structs, enums, etc will be prefixed with Axis and externalised #defines
will be prefixed with AXIS_. This is to avoid nameclashes with user code (AXISCPP-202). This
C binding layer will be a thin layer written in C++ which invokes the underlying C++ engine.
It will maintain the instances of the underlying C++ objects. The C programming interface
should be natural for C programmers to use. Storage returned to C applications, where the
equivalent C++ storage would be freed by delete by the application or in a destructor, will
either be malloc'ed in the C bindings layer so that it can be freed by the application, or
else a freeStorage function will be provided that will delete the storage.

The structs in AxisUserAPI.hpp will be changed to classes and their equivalents in AxisUserAPI.h
will be structs. So the C binding layer will have to copy these classes into structs. (AXISCPP-149)

The generated stubs will change to make use of the new C dynamic API. Generated stub functions
will be prefixed with the port name. Generated types will have different sizes in C and C++
since they contain classes in C++ and structs in C. There may be two versions of the generated
stub APIs: one passing stub handles and the other not. Passing handles (pointers to opaque
C++ classes) has the advantage of enabling the application to manage multiple instances of
the same stub. Not passing handles has the advantage of making simple applications easier
to code. So maybe both will be generated, or maybe it should be a command line switch on wsdl2ws.
C applications using generated stubs should be able to use the C bindings layer to invoke
instance methods on the Stub class like a C++ application can.
View this comment:

View the issue:

Here is an overview of the issue:
        Key: AXISCPP-210
    Summary: Add back in C support in 1.5
       Type: New Feature

     Status: Open
   Priority: Critical

    Project: Axis-C++
             Basic Architecture
   Fix Fors:
             1.5 Alpha
             1.5 Alpha

   Assignee: Mark Whitlock
   Reporter: Mark Whitlock

    Created: Tue, 19 Oct 2004 6:25 AM
    Updated: Tue, 19 Oct 2004 7:36 AM

C support is removed in 1.4. This JIRA adds back in C support in 1.5. This JIRA is a good
place to add in the results of any investigations concerning C support.

This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:

If you want more information on JIRA, or have a bug to report see:

View raw message