[DotGNU]API A document

[Myrddian]

Well I have written another document discussing what API's we should support, 
it's far from
complete, and I think people might want to correct/contribute to this.

If people want this on the web please inform me. It's more of a Blurb of ideas 
and hence not fit to be a document specification
it's probably full of errors.


Any how if you spot errors please inform me. I might also put it on CVS so 
people can modify the document.

For CVS please go to savannah.gnu.org

Follow intructions there :) 


Hope to talk to you all soon.


__________________________________________
Myrddian <myrddian at bigpond.net.au>
-------------------------------------------
" Pero el Viento no mas sabe, a donde duerme my viejo
  Con su pena de hombre pobre y dos valas en el pecho. "
                                      
                                       Patricio Manns

Application Programing Interface

Layout

For the DotGNU Project.

Version 0.1A

By

Enzo-Adrian Reyes (address@hidden)

Introduction

This document is a general idea on what the basic API for the DotGNU platform would be. It would be what I would consider the most minimal set's of API that should be accessible by DotGNU platform programs. I would also consider other things which might be of importance in the appendix, some of these might not be directly related to the API, however I would consider important to mention.

Please note that I will not discuss the individual functions or Objects for the mentioned API. This is beyond the scope of the documentation.

Considered API's and Rationale

DotGNU is both a framework and an platform. Programs can either use one or both parts (hence allowing flexibility). A program using the framework may not be a native DotGNU application, so these programs can use the native O.s.'s API. However a program using the DotGNU platform does not have the luxury of having accessible OS' API routines, or objects.

Posix, I think should be our primary low level API for the DotGNU platform, this includes threads and what ever Posix specifies. Why Posix? Well its a mature API, and most importantly it's widely adopted. Although at the moment I am only aware of POSIX 1, and POSIX Threads.

Note: If anybody here knows about POSIX please Contribute to this document.

Another API we should be able to support is GTK, now why not Gnome, well Gnome is a desktop, and not appropriate for windowing. However I think that DotGNU should also support another Widget layer on top of GTK on the Platform side, which should be easier to program on compared to GTK.

Resource Locating String API's to transport, generate, also interface to the RLS system.

Registry. The Registry Subsystem API

DotGNU Framework API calls. This is crucial as this allows access to remote objects and services (this includes both the Registry and RLS API). Over all this API has yet not been fully implemented or designed.

Full UNIX Sockets, I don't know if this is specified in POSIX, however this should be available for the Platform, as not everybody may want to use the DotGNU framework

Component Interfaces. Well this could mean several things, however it should be noted that the above is not a complete list, but it should be our most basic API for programs to use. In order to make our system rich in flexibility, we need a way to extend its capabilities. Component Interfaces allow this to happen, this way we can extend the DotGNU system and not break it's basic API functions and existing supported software. Most components would be built around an Object Oriented Paradigm, however ways to allow access via standard Procedural languages, should be available.

Some optional API which we might include would be Multimedia support, such as OpenGL and Sound (OpenAL, or some other sound API). Other things such as Image handling routines. Another API we should be able to support would be the ability to handle Dynamic Data Exchange between programs and services.

Conclusion

With the mentioned API support this should allow any programmer to write any type of software he wishes on DotGNU. From Word processors to fully fledged web services using both the DotGNU platform and framework.

Appendix.

Well these are idea which might not be in the above category, but I thought I'd mention any how.

CORBA, including support for CORBA in DotGNU I think should be important, it allows people to move services across to our platform in shorter time. CORBA is already well established, support for it is every where. Including it as an optional API, I think is wise.

Java RMI. If support for Java is to be included in DotGNU a way to handle RMI requests should also be considered. Although I don't think a fully functional RMI implementation is required, a way to handle RMI should be available either by using CORBA. This should allow Java Beans to use RMI to communicate to a DotGNU service, although it's well known that Java also has CORBA support.

Web forms, dynamic content on the web is a good idea. DotGNU should be able to do this, if not support a method on how to do this by either providing a way to allow this to happen. This can be done already with out the need for DotGNU, however we should allow a way for these ways to access the DotGNU framework and the Platform allow access to these ways also.