Difference between revisions of "IUP ISI/MediaWiki-Silk/Architecture"

Jump to: navigation, search
(Introduction)
m (fmt)
Line 1: Line 1:
== Architecture document ==
 
 
 
== Introduction ==
 
== Introduction ==
 
  
 
'''API'''
 
'''API'''
Line 16: Line 13:
 
'''Synchronous or asynchronous?'''
 
'''Synchronous or asynchronous?'''
  
Synchronous
+
Synchronous
  ○ Advantage
+
* Advantage
      ■ No signals in the public API
+
** No signals in the public API
  ○ Disadvantage
+
* Disadvantage
      ■ Multi-threads when used in interface to avoid freeze
+
** Multi-threads when used in interface to avoid freeze
      ■ Latency troubles may increase waiting
+
** Latency troubles may increase waiting
  
Asynchronous
+
Asynchronous
  ○ Advantage
+
* Advantage
      ■ Don’t block the interface
+
** Don’t block the interface
  ○ Disadvantage
+
* Disadvantage
      ■ Wait the signal to access to the result
+
** Wait the signal to access to the result
  
 +
'''Develop Unique class vs multiple classes?'''
  
'''Develop a class or some classes?'''
+
Unique class
 
+
* Advantage
● A class
+
** No memory managing
  ○ Advantage
+
** The request calls are normal : wiki->allpagesRequest()
      ■ No memory managing
+
* Disadvantage
      ■ The request calls are normal : wiki->allpagesRequest()
+
** Readability
  ○ Disadvantage
 
      ■ Readability
 
● Some classes
 
  ○ Advantage
 
      ■ Readability
 
  ○ Disadvantage
 
      ■ The memory management
 
  
 +
Multiple classes
 +
* Advantage
 +
** Readability
 +
* Disadvantage
 +
** The memory management
  
 
== Technical contacts requirements ==
 
== Technical contacts requirements ==
Line 54: Line 50:
 
   connect(mw, SIGNAL(allpagesResult(QList<MediaWiki::Page>)),
 
   connect(mw, SIGNAL(allpagesResult(QList<MediaWiki::Page>)),
 
               SLOT(allpagesProcess(QList<MediaWiki::Page>));
 
               SLOT(allpagesProcess(QList<MediaWiki::Page>));
 
  
 
== MediaWiki UML ==
 
== MediaWiki UML ==
Line 64: Line 59:
 
MediaWiki data. For this, developers call a request like allpagesRequest() who send the request with the QNetworkAccessManager. To process the result, developers connect the signal allpagesResult() with his own slot.
 
MediaWiki data. For this, developers call a request like allpagesRequest() who send the request with the QNetworkAccessManager. To process the result, developers connect the signal allpagesResult() with his own slot.
 
Because the class MediaWiki needs to emit signals, MediaWiki inherit QObject.
 
Because the class MediaWiki needs to emit signals, MediaWiki inherit QObject.
 
  
 
'''Why don’t separate the code'''
 
'''Why don’t separate the code'''
Line 70: Line 64:
 
To follow the first development of the MediaWiki class and with the agreement of the technical contacts, we don’t separate MediaWiki and its requests.
 
To follow the first development of the MediaWiki class and with the agreement of the technical contacts, we don’t separate MediaWiki and its requests.
  
 
+
'''Who manages the memory?'''
'''Who manage the memory?'''
 
  
 
There is one class, so the library can manage the memory.
 
There is one class, so the library can manage the memory.
  
'''
+
'''Why QNetworkAccessManager?'''
Why QNetworkAccessManager?'''
 
  
 
It’s the Qt class for HTTP requests and it is asynchronous. By the way, we can use this class in a synchronous way using QEventLoop.
 
It’s the Qt class for HTTP requests and it is asynchronous. By the way, we can use this class in a synchronous way using QEventLoop.
 
  
 
'''KDE library?'''
 
'''KDE library?'''
  
 
At this time, we don’t use KDE library because Qt provides the necessary.
 
At this time, we don’t use KDE library because Qt provides the necessary.
 
  
 
'''Namespace'''
 
'''Namespace'''
  
 
To avoid name conflicts with others libraries, we propose to define a namespace like silk::. mediawiki:: was a possibility but there will be a redundancy (mediawiki::MediaWiki).
 
To avoid name conflicts with others libraries, we propose to define a namespace like silk::. mediawiki:: was a possibility but there will be a redundancy (mediawiki::MediaWiki).
 
  
 
'''Binary compatibility'''
 
'''Binary compatibility'''

Revision as of 15:34, 21 October 2010

Introduction

API

The API is composed of some classes (UserGroup, Namespace, General, Page...) and a MediaWiki class to access data. Library architecture at the begining

The library is composed of a unique class: MediaWiki.

Choice architecture

Synchronous or asynchronous?

Synchronous

  • Advantage
    • No signals in the public API
  • Disadvantage
    • Multi-threads when used in interface to avoid freeze
    • Latency troubles may increase waiting

Asynchronous

  • Advantage
    • Don’t block the interface
  • Disadvantage
    • Wait the signal to access to the result

Develop Unique class vs multiple classes?

Unique class

  • Advantage
    • No memory managing
    • The request calls are normal : wiki->allpagesRequest()
  • Disadvantage
    • Readability

Multiple classes

  • Advantage
    • Readability
  • Disadvantage
    • The memory management

Technical contacts requirements

First, the technical contacts want a asynchronous interface: ”Even if you use a QEventLoop,you'll often need different threads in the application, and those can be a bitch. You can have a look at the current MediaWiki class to how those signals / slots should look like.”

Secondly, to call a request, the code should look like:

  MediaWiki * mw = new MediaWiki(“mon_url”);
  mw->allpagesRequest();
  connect(mw, SIGNAL(allpagesResult(QList<MediaWiki::Page>)),
              SLOT(allpagesProcess(QList<MediaWiki::Page>));

MediaWiki UML

Uml.png

MediaWiki

The MediaWiki class allows developers to call asynchronous request to access the MediaWiki data. For this, developers call a request like allpagesRequest() who send the request with the QNetworkAccessManager. To process the result, developers connect the signal allpagesResult() with his own slot. Because the class MediaWiki needs to emit signals, MediaWiki inherit QObject.

Why don’t separate the code

To follow the first development of the MediaWiki class and with the agreement of the technical contacts, we don’t separate MediaWiki and its requests.

Who manages the memory?

There is one class, so the library can manage the memory.

Why QNetworkAccessManager?

It’s the Qt class for HTTP requests and it is asynchronous. By the way, we can use this class in a synchronous way using QEventLoop.

KDE library?

At this time, we don’t use KDE library because Qt provides the necessary.

Namespace

To avoid name conflicts with others libraries, we propose to define a namespace like silk::. mediawiki:: was a possibility but there will be a redundancy (mediawiki::MediaWiki).

Binary compatibility

For ensure the binary compatibility, we’ll use only a pointer to MediaWikiPrivate, which will contain attributes. In this case, modify the attributes doesn’t fail a class which uses MediaWiki.


Content is available under Creative Commons License SA 4.0 unless otherwise noted.