Hi Sergei, first of all, I appreciate your mail. It describes some problems we were having in the past. I would like to see more developers in the project, and I think the precondition for this is that we resolve some of the issues you raised.
> 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). I just dug through the old mails. There was some discussion and consensus, but I could not find a "canonical" document that summarized the conventions you mentioned. Perhaps we should have taken the time to put them down when we started, but it's not too late, I think. I think it would help if we published this on the Wiki - Scott has already preparing a Wiki entry to start this. Perhaps we can agree to follow a set of guidelines when coding in the future. See http://wiki.openxpki.org/index.php/Developer_Guidelines > 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? Agreed. In the past, we did our best to commit all changes the community could actually use to the upstream repository. E. g. the SmartCard personalization stuff is a spin-off of the customizations we did here. We will continue to do so with our current development, but we need to resolve technological and possibly legal issues first before we can adapt our current development for upstream release. > 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. I understand your problem, and I agree that we need to remedy the situation. It's not easy for us, though, because we are trained to think about western algorithms as basic building blocks. We need to constantly remind ourselves that this is not necessarily the case. > 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. I hope we can merge the code lines back together without too much effort. > That is why we here have at least partial well tested solution for > nearly all points listed below. Sounds good. We also have some contributions we are going to add to the project in Q3 or Q4 of the year, but as I said currently we cannot commit it upstream due to technology restrictions. > 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. I would appreciate that. Let's discuss these issues in more detail. > 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? I agree, and I think a discussion is sensible and useful. > 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? I think we should compose a release plan with all open issues to resolve in order to get a sensible state everyone can work properly with. My top issues are - documentation - error logging - integration of non-western cryptography - integration of OpenSSL 1.0 I would be willing to contribute my part of this, e. g. add missing log statements and clean up western-cryptography-mess wherever I introduced it. Possibly elsewhere as well :) My problem is that our current project is on a tight schedule and I will only have limited time to work on the above until about end of June. > =============================================================== > > 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. 100 % agreed. > - 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. Agreed, but we need to understand the pitfalls and hence need your input and experience. > - 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. Coincidently OpenSSL 1.0 was released, I think this is an important step, and OpenXPKI 1.0 should support OpenSSL 1.0, of course. We need to understand how we can solve your problems. > - 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? The current web interface sucks. We have some ideas how to replace this, but this is currently only an idea (although a sexy one). A wizard-like mode for users is what we want as well. > - 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. No flash, of course. But an Ajax interface seems to be the way. We have had a look at some promising technology and plan to start a prototype in summer. > - Web interface: follow w3 validation. Now html code generated by > Mason is full of unbalanced tags and misplaced css statements. See above. > - 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. Agreed. > - Perl Best Practices by Damian Conway. There are parts of ox code > where this is not followed. Agreed, but there are some Best Practices which I do not find useful. However, it would help to obey them... > - 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. Yes, one of my top priorities. I would like to go through the whole source code and introduce sensible log statements that allow 1) to find out about error conditions properly and 2) follow the execution flow. cheers Martin ------------------------------------------------------------------------------ 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
