Plz don't say you didn't get any answer
You got one, you just didn't read it!
---
By Youness
Where did you request to help on documentation ? also, if you want to
help, then help.. write some doc, you don't need to have our
permission to do it!!
------
Le 05-10-31 à 19:59, GrdScarabe a écrit :
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi again ...
Would it be possible to open a section on the WiKi to discuss about
this
problem together ? and start to redact some specifications ?
And in the same time ... can I have a Wiki account ? I've already
proposed myself to help redacting documentations and translating the
WiKi in French ... but I've still no answer :(
GrdScarabe
GrdScarabe wrote:
I think Karol was very right in speaking of Core/user and Global/
per-user as
separate concepts. GUI parts and even protocols can be per-user.
Think of
having different GUI's (one user may prefer another GUI than
another). Also a
developer may want to use an 'unstable' protocol plugin for
testing, while
other users may want the default, stable protocol plugin.
+--------------------------------------+
+------------------+
| Extensions | |
Dependencies |
+------------+------------+------------+
+ |
| Prot x | Prot z | ..... | Categorise |
Conflicts |
| GUI y | GUI xyz | | <=========
| |
+-------------------------+------------+ Unload +
Resolution |
| Category 1 | Category 2 | Category i |
| |
+------------+------------+------------+
+------------------+
\/ Plugins Events /\ /\ Module
loading \/
+--------------------------------------------------------------------
--+
|
Core |
| (Event dispatching
system) |
+--------------------------------------------------------------------
--+
|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NETWORK
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
+--------------------------------------------------------------------
--+
The previous scheme is the one which represent the most carefully
what I
understood ...
- The Core listen the network and Plugins output and handle events
depending on what it's received.
- The plugins react to events received by the core, and send
theirs in
reaction to an event or anything else inside the plugins (user action
for GUI, protocol event for protocols, ...)
- When a module (plugin) is loaded or unloaded, the conflits and
dependencies are checked and some others plugins are loaded or
unloaded
automatically
- this way, all plugins are per-user-plugins ... what kind of
plugins
would be core plugins ?
- Can a plugin belongs to several categories in the same time ?
Why not
... we can imagine a plugin Jabber for instance that conflict with
noone
else and is present in every categories ... no ?
Good idea, although I would say 'dependency list' rather than
'priority list'.
This will also eliminate the need of distinguishing between
Core- and
User-plugins. Also, it is good to make Plugin-categories. This
way you can,
for example, make a GUI-plugin depend on the Protocol group, so
it will work
with either a MSNP9 plugin, or MSNP11, or Jabber, or whatever....
(Please note that per-user plugins can depend on global ones,
but global
plugins cannot depend on per-user ones, because that would break
aMSN
startup.)
Within a group there should also be a way to set
'conflicts' (like MSNP9
conflicts with MSNP11, but using any of them together with a
Jabber plugin
should be possible). But this is quite complex, I haven't a real
good idea
yet.
The dependencies/conflicts can be modelised thanks to a graph with
labelled edges (with labels : depend on, need, conflict with, ...).
Incorporing the core in the graph simplify everything. We just
have to
find a path from the plugin to the core in the graph without using
"conflict" edges. and checking that there is no cycle in the subgraph
using "conflict" edges.
For instance :
MSNP34 ----------need--------------+
^ |
conflict |
| V
Jabber --need--> PluginX --need--> core
Ok ... the example is really bad, but the idea is there. That's for
representing the dependencies in memory. Now for representing the
dependencies in the "plugins packages", I propose to take a look
at how
the debian packages are managed. I think their dependencies
management
is the best ever. For instance, the package "tar", I've selected only
the interested feature for us :
Package: tar
Essential: yes
Priority: required
Version: 1.14-2
Pre-Depends: libc6 (>= 2.3.2.ds1-4)
Suggests: bzip2
Conflicts: cpio (<= 2.4.2-38)
What do you think about ?
GrdScarabe
- -------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Amsn-devel mailing list
Amsn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amsn-devel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFDZr4NPmfsnt4Id3wRAp0tAKCpHRlIvY7sgBgIjQbBJeCP+I1NzgCeNrdc
tjb9i4H+d+/hEyNRn01kAbg=
=82ev
-----END PGP SIGNATURE-----
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Amsn-devel mailing list
Amsn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amsn-devel
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Amsn-devel mailing list
Amsn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amsn-devel
