Étoilé CoreObject Presentation
==============================

Why not rethink DO?
-------------------

Pro:
- Very straightforward to use
- Flexible and powerful
- Not verbose
- 15 years later, Microsoft is providing a nice .Net API under WCF name which provides both DO and NeXT Services features to Windows :-) Note: WCF stands for Windows Communication Foundation


Why rethink DO in Étoilé perspective?
-------------------------------------

Cons:
- Poor name server (in part because it follows Mach model weak on some points)
	 - No default naming scheme
	 - No security policy or model
	 - Poor replication, synchronisation distribution features across name servers
	 - No lookup chains
- Abstract and very concise API that makes it difficult to understand until you really grasp it.
- Language support limited to Objective-C
- No integration with modern stuff like XML-RPC, Web services etc.


Introducing CoreObject
----------------------

CoreObject has been thought to fix these issues, it introduces initially:
    - New name server (branded as 'object server')
    - Lookup chains
    - Translators (aka Virtual Objects System support)

Next step would be:
    - Security model

Ultimately it may include:
    - Actor semantic (based on StepTalk) with very basic XML format for serialization
    By delegating to StepTalk:
	   - programming languages support
	   - scripting support


Flexible Object Type Support
----------------------------

Apple has the solution: Uniform Type Identifier (UTI).

Will become default File types mechanism in Étoilé and will be extended to become Default object type mechanism in CoreObject.

Étoilé rules:
    - File UTI are mandatory
    - File type extensions are optional

Will allow to build Roles logic very easily when combined with the nameserver lookup chains possibility.

CoreObject


Future Features Evaluated
-------------------------

In future, CoreObject performance or flexibility could be enhanced by:
    - Transactional support (would rely on an HOM model through a trampoline), the implementation would be inspired by Vanguard micro-kernel message chains
    - Actor semantic
    
Note: An actor is an aggregate of services/messages from other objects or programs, presented with its own object interface and logic. It can be described as proxy potentially mapped to several objects (or often parts of them) and not not only one.

At a later point, transactions support  may be implemented at CoreObject level (both object server and Objective-C would be concerned by the extensions) to have transactional support built-in and improve performance (as introduced by Vanguard message chains).


Unified ACL Security Model
--------------------------

The security model is planned to be a simplified version of what has already been implemented for Spring or Hurd name servers. That means an ACL based Security Model, set per published object. This model which would allow policy oriented security rules by using the nameserver as a policy store.


Looking up my lookup chain
--------------------------

It implements lookup chains, that could be roughly compared to Hurd translators.
Lookup chains have many uses like to take an example, know what role and program is related to an UTI.
A lookup chain happens when a lookup on a domain returns another domain (referenced in the object server), then the latter evaluates the returned domain and repeats the process until the returned object isn't a domain object anymore.


Lookup Chain By Example
-----------------------

What's a lookup chain ?

Web server  example :

[objectServer objectForURL: @("http://www.etoile-project.org/cool.html");

UTI/roles lookup happens inside the object server and triggers a request/result interaction with HTTP server.

Finally CoreObject server returns :

string object which contains html/txt content of the requested page.

What's a lookup chain ? 

Web server example in detail :

What's a lookup chain ? 

Open document example :

What's a lookup chain ? 

Open document example in detail :


--- blabla

Writing such a server is pretty hard when you consider concurrency issues.

To simplify such development, the solution is to rely on a language which makes easier concurrency support with stuff like :
- coroutines
- auto-deadlock detections
- futures/continuations

Io provides all these features, that's why it is a probably a good choice to write the object server itself in CoreObject