Hi developers,
In the early days of the OpenXPKI (Julia calls it just "ox" for
short) a list of strategic development conventions was accepted
(please find attached below).
Actually it was this list of conventions which made ox project so
interesting and nice-looking for me. I have clearly seen a road
towards a system which is transparently simple in design, reliable,
scalable, modular, suitable for collective development, easy for
maintenance etc.
Later on each of these conventions has been gradually neglected:
partially or completely.
Maybe this dissolving of conventions was due to a rush, when it was
necessary to give a certain functionality to the customer to a
certain date? Then why commit it to the main branch?
Sometime I (or Julia) tried to edit e.g. careless commits related to
cryptography. Then we gave up. In case you do not know: Russian
cryptography does not work in ox since 1.5 years ago. When I need a
quick deploy of ca for GOST, I am using that old version of ox.
It is not very easy and interesting to convert a left-foot style
programming into a conceptually clean code. And I do not feel myself
as a policeman to monitor rules here.
At that time we here had to branch off the main ox development.
Also, we developed a number of systems (beyond the scope of PKI)
which were very close to the initial beautiful design concept of ox
and were built of the same building blocks, and heavily used a code
of ox. That old good ox which was older than 2 years. Our sporadic
commits to the main branch of ox during this period was a sort of
out of despair.
That is why we here have at least partial well tested solution for
nearly all points listed below.
In separate future messages I can describe in detail each point
mentioned below, practical solution for them, their status, (heavy
load) testing results. This message is just an advance
Zusammenfassung of the whole bunch of problems.
It would be nice to know what is your general opinion, do we
re-agree about a list of conventions below?
Do we need a discussion like this at all?
If yes, then more question:
Can we decide how these available solutions can be incorporated into
the main branch?
Major review of the last 2 years of coding?
Or just full roll back with gradual new filling at a new level of
quality of programming?
Can we divide a labor?
All the best, Sergei
===============================================================
A list of strategic development conventions.
- System logic should be given to workflow facility only. If you can
invent a system task related to ox, which can _not_ be described
with a regular workflow, this will be an outstanding scientific result.
Massive programming of the system logic in perl leads to a mess.
Solution with workflow instance shadowed by a forking process in
memory is not just ugly. It looses data at any noticeable system
load level. Hence it is simply _not_ appropriate.
- Cryptography abstraction concept as in
http://www.openxpki.org/docs/crypto-plug.html
is fully neglected. Problems with GOST and even with certain modes of a
standard CSP from Microsoft.
- Future moving of ox to openssl-1.0 could be a plague, because this
version heavily uses Cryptography abstraction concept which is very
similar to the one referred above.
- Web interface: Artificial Intelligence (AI) guidance of the user.
Web interface should guide a user along a chosen workflow. It should
do everything by itself, unless human action is absolutely
necessary. And never show inactive buttons like Microsoft Word does.
At the moment this AI is not available everywhere. Also it requires
major low-level handcrafting with perl-Mason. Does anybody know some
sort of automation (or moving to high-level tool) to achieve this?
- Web interface: cross browser portability e.g. as in
http://developer.yahoo.com/yui/
css and javascript browser-portable library.
Massive use of industrial level javascript library could help with
cross browser portability and web design quality.
Let me doubt that use of flash technology can add clarity at the
present stage.
- Web interface: follow w3 validation. Now html code generated by
Mason is full of unbalanced tags and misplaced css statements.
- Web interface: i18n. Translators seldom care about size of the
buttons. Simple "save" is often translated by a "very long
blah-blah-blah phrase", thus ruining initial web design idea (if
such an idea existed at all). We should measure on-screen dimensions
(like width of a menu button) in % of window width, and not in chars
as now. Translators of web interface should check the resulting look
before committing i18n files.
- Perl Best Practices by Damian Conway. There are parts of ox code
where this is not followed.
- Error handling should be user oriented, rather than developer
oriented. Detected error should help user to understand what to do
here and now, instead of mailing to the list with copy-pasting of
unhuman encriptions. Major conceptual turn in error handling is
badly needed.
===============================================================
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
OpenXPKI-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openxpki-devel
