1. Revision history
2. Background
3. Main Bus name
4. Services
5. Clients
6. Database identifier
7. Module or class identifier
1. MgdSchema
1. Create
2. Update
3. Delete
4. Purge
5. Get
2. Replication
1. Import
2. Export
8. Messages
9. References

Revision history

• 2008-04-30, created by Piotr Pokora
• 2008-05-26, clarified message content ( Piotr Pokora )

Background

As D-Bus allows to create self, freely defined paths for objects, it might be confusing to send messages to other objects without any knowledge about their particular paths. This document defines D-Bus messages and objects' paths, at which instances has been created.

'midgard_article' class name is used in every example below.

Main Bus name

• org.midgardproject - the main Midgard D-Bus service name
• /org/midgardproject - the main Midgard D-Bus service path

Services

Services objects can be created by any application as long as they conform to this mRFC.

Clients

Clients objects can be created by any application as long as they conform to this mRFC. For asynchronous massages, Midgard API shall provide automatic messages for main I/0 operations.

Database identifier

To limit possible collisions and provide clear and safe services' and clients' identifiers, Midgard configuration name is appended to main service's path. Midgard API implementation should not require to append this name by application, and path with configuration name should be created automatically.

For example, if application has been initialized with default 'midgard' configuration, the base path for services and clients shall look like this:

/org/midgardproject/midgard

Of course for configuration named 'myconfig', the base path shall look like this:

/org/midgardproject/myconfig

Midgard application should not be aware of configuration name as both service and client will be created for the same base path. Midgard API for D-Bus should require only module or class names.

Module or class identifier

Services' paths should be created with classes' names, and if possible with module's or feature's names to separate services objects. For example all user defined MgdSchema classes should be created for 'MgdSchema' path. Class method should be appended to path to finally identify service's name.

This document must define clear path's method name, if class' real method name can not be appended to path or any other name suits better.

MgdSchema

Services for MgdSchema should be created at path with following tokens:

• mgdschema
• class name
• method name

Every mgdschema class' service or client shall be initialized with the same convention.

Create

'create' shall be appended to object's path.

/mgdschema/midgard_article/create

On success, Midgard API shall send asynchronous message to object at path.

Update

'update' shall be appended to object's path

/mgdschema/midgard_article/update

On success, Midgard API shall send asynchronous message to object at path.

Delete

'delete' shall be appended to object's path

/mgdschema/midgard_article/delete

On success, Midgard API shall send asynchronous message to object at path.

Purge

'purge' shall be appended to object's path

/mgdschema/midgard_article/purge

On success, Midgard API shall send asynchronous message to object at path.

Get

'get' shall be appended to object's path for one of these methods:

• constructor
• get_by_guid
• get_by_id
• get_by_path

• get_parent

  /mgdschema/midgard_article/get

Midgard API implementation will send asynchronous messages in above cases, only if object is successfully retrieved from database.

Replication

Services for replication should be created at path with following tokens:

• replication
• class name
• operation

Import

/replication/midgard_article/import

Export

/replication/midgard_article/export

Messages

Messages sent to Midgard D-Bus services should contain:

• Serialized object as xml data

References

• http://dbus.freedesktop.org/doc/dbus-tutorial.html