CAcert Code Development list.

[Mario Lipinski <mario AT cacert.org>]

Hi,

Am 19.12.09 04:28, schrieb Christopher Etz:
>       acceptable performance. As a consequence, the API should be
>       oriented towards the activities of the business processes.
>        From what I understand, the API is currently more oriented
>       towards the entities (classes, instances) that the business logics
>       knows. E.g. creating a new member would result in individual calls
>       to create the member, a name, a DoB, an email address and perhaps
>       other things. Another problem is, that it is hard to preserve the
>       consistency of the database. E.g. every application deleting a
>       member must know and implement calls to delete the name, the DoB,
>       the email addresses, perhaps the assurances and so on.

I think here the concept of piggybacking could be used. Put any 
information of interest in the request/reply.

>       One point that I miss in the current information within the wiki,
>       is the kind of response that the services produce. I expect, you
>       think of XMLs containing the requested information. Then, it is up
>       to the different applications to decode (unmarshall, deserialize)
>       the response. This would require to implement similar code in
>       every programming lanuguage of the different applications. Or am I
>       wrong here?

I guess it will be some kind of XML. Maybe even SOAP. But this is still 
open.

>    2. Hand written code
>       Between the lines (i.e. not being expressed explicitly) I've got
>       the impression, that you expect all code to be written manually, like:
>           * individually coded SQL statements
>           * applications written in PHP, Python or whatever, building
>             the HTML pages, communicating with the business layer and
>             unmarshalling / deserializing the returned results
>           * Coding some functionality for a modern ("nice and sexy")
>             user interface in JavaScript

We might use some code generators, but I have some objections against 
some more magic frameworks. But maybe this is also I have not seen them 
in practice and do not know how to get them to work easily.

>    3. Technologies that might be useful
>       Within the architectural overview, a decision should be suggested
>       about how to access the database. The technologies of interest are:
>           * Pure SQL via JDBC (if the programming language is Java)

I tend to do so. Maybe some object oriented framework to constructing 
queries. I know Zend Framework for PHP has something like this, but do 
not know about anything for Java.

>           * Use of an ORM (object relational mapper, such as Hibernate)

I had a look at hibernate some days ago and do not like the concept. 
Maybe I am just getting to old for this kind of mondern technology.

>           * Use of JPA (possible with Tomcat) or even JTA (requiring an
>             application server like JBoss)

Don't know anything about this.

>       The user interface could also be coded with some standard
>       technology such as
>           * JSP (JavaServer Pages)
>           * JSF (JavaServer Faces)
>       I personally, would vote for JSF, because there are a lot of
>       implementations, even open source, that offer the chance to have a
>       modern user interface: Some of them implement AJAX or other
>       JavaScript code automatically, without forcing the developer to
>       code this manually. Candidates are:

This is out of my scope whithin the business logic. But this could be 
anything which is able to talk to our business logic.

>       In my opinion, PostgreSQL requires regular maintenance (the famous
>       vacuumdb at least) and might not be the best option when
>       recoverability is a high requirement.

Postgres can do auto vacuuming in recent versions and also had made 
great inprovements over the last years. So I tend to using postgres.

>           * Ingres: Used to be an important player in that area (agreed,
>             that's decades ago), now turned into open-source, has
>             excellent features for performance and recovery.

Maybe I should have a look here, but did not know about it being a 
resonable alternative open source database.

>    5. Thoughts on the approach
>       I saw some code fragments in the SVN repository already. But I
>       believe, it's too early to continue here.

If we have good code working it would be appreciated. As long these are 
only some tryouts and it is not continued in a reasonable time, 
everything could be changed.

>          4. Starting the implementation. Here, I presume that BirdShack
>             will be a re-write of new code and not a patchwork on old code.

Yes, it is definitely a rewrite. If someone improves the documentation 
it is good. If someone comes up with good code, this could also be a 
base which can be used.

Saying that, someone needs to do something and needs to do it properly.

--
Mit freundlichen Grüßen / Best regards

Mario Lipinski
Board member,                       E-Mail: 
mario AT cacert.org
Organisation Assurer (Germany),     Internet: http://www.cacert.org
Wiki/Issue admin
CAcert

Support CAcert: http://www.cacert.org/index.php?id=13
                http://wiki.cacert.org/wiki/HelpingCAcert

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature