The result is:

• In Away3D 2.4 you can get only Phong shading by using a CompositeMaterial with two layers, one being a TransformBitmapMaterial, and one a white or gray PhongColorMaterial for the shade. You can not get the faster flat shading, because WhiteShadingBitmapMaterial does not implement ILayerMaterial.
• In Away3D 2.3 you can get both Phong shading and flat shading by using a CompositeMaterial again, with two layers, one being a TransformBitmapMaterial, the other being a white or gray PhongColorMaterial or a white or gray WhiteShadingBitmapMaterial.

Detailed discussion of possible ways and why they are possible or not:

WhiteShadingBitmapFileMaterial modification for Away3D 2.4. This would enable flat shading together with bitmap transformation in Away3D 2.4, but it is quite some effort. So the better alternative would be to switch to Away3D 3.5 and proceed as above. But, for an outline: this needs the implementation of WhiteShadingBitmapFileMaterial as an extension of BitmapFileMaterial (which again is a TransformBitmapMaterial, enabling bitmap transformations). Another option would be to extend BitmapFileMaterial to include flat shading; which could be quite a complex thing. And another option would be extending WhiteShadingBitmapMaterial to include bitmap transformation abilities. Which could be the simpler alternative.

Using BitmapMaterialContainer / CompositeMaterial. Works, with the limitations stated above. The idea is to combine the current BitmapFileMaterial with an overlayed, semi-transparent or otherwise composited white shaded material. In Away3D this cannot be a WhiteShadingBitmapMaterial, as this class does not implement ILayerMaterial which is needed to be used for BitmapMaterialContainer. In Away3D 3.5 however, the corresponding CompositeMaterial operates on BitmapMaterial objects, so that using WhiteShadingBitmapMaterial as a composite layer becomes possible. It seems that such a composite material solution has also a good performance for not-too-complex scenes. Some hints to parameters that influence compositing:

• BitmapMaterial#alpha and / or #blendMode attributes
• BitmapMaterialContainter#transparent

Using a pre-made composite material like a Phong or Dot3 shading material. Using such a material on its own does not help here, as these materials do not allow texture bitmap transformations in either Away3D 2.4 or 3.5.

Away3D offers the CompositeMaterial class that allows to combine different material layers into one, using different compositing modes. (Note that this applies to Away3D 3.4; in version 2.4, the concept is split so that you have a class BitmapMaterialContainer additionally, which is only for cached materials, that is those that are not changed once applied.)

In my experiments I found that one can get some surreal, crazy materials by combining a texture with a “shade” in strange ways:

var textureMaterial : BitmapFileMaterial = new BitmapFileMaterial(imageUri, {precision: 0, repeat: true, smooth: true, blendMode: BlendMode.NORMAL});

var shadeMaterial1 : PhongColorMaterial = new PhongColorMaterial(0xffffff, {shininess: 5, specular: 0.5, alpha: 1, blendMode: BlendMode.DIFFERENCE});

var shadeMaterial2 : PhongColorMaterial = new PhongColorMaterial(0xffffff, {shininess: 5, specular: 0.5, alpha: 1, blendMode: BlendMode.LIGHTEN});

var crazyMaterial1 : CompositeMaterial = new CompositeMaterial({alpha: 1, color: 0xFFFFFF});

crazyMaterial1.addMaterial(textureMaterial);

crazyMaterial1.addMaterial(shadeMaterial1);

var crazyMaterial1 : CompositeMaterial = new CompositeMaterial({alpha: 1, color: 0xFFFFFF});

crazyMaterial1.addMaterial(textureMaterial);

crazyMaterial1.addMaterial(shadeMaterial2);

FinTS 3.0 is actually a remaining of HBCI 2.2, and is meant to be the successor of HBCI that way. The technical details do not deviate that much, so that it can be expected that HBCI open source implementations will integrate FinTS in the future.

For the best discussion about this that I found so far, see this: http://www.ruby-forum.com/topic/177210

There seems to be only two (or two major) open source HBCI implementations: HBCI4Java and AqBanking. Of these two, AqBanking seems to be the preferrable one (yet without respect to Ruby integration). Reasons:

• AqBanking is behind several major HBCI open source applications: AqFinance, QBankManager, GnuCash, KMyMoney, AqBanking-CLI (source), while HBCI4Java is behind Hibiscus (source).
• AqBanking is in active development as of 2010-08, while HBCI4Java’s latest version is from mid 2009.
• AqBanking offers HBCI, OFX and PayPal in the open source version, while HBCI4Java offers HBCI (source).
• Both are cross-platform compatible for Linux, Mac OS X and Windows.
• AqBanking is twice as popular as HBCI4Java (40,000 vs. 18,000 Google search results).

Also, the integration into Ruby is simpler. One can either use exec() with the command line client coming with AqBanking as the simplest solution, or use the Ruby C bindings with the AqBnaking library, which is written in C (see here). With HBCI4Java, one could either use Ruby Java bindings (like they do in the POI project), port the application to JRuby, or a rather solution using the GUI tool Hibiscus and XML-RPC (example), which is however quite clumsy when it should be used on a server (as it’s a GUI tool).

Result: I recommend to use AqBanking with CLI based or Ruby extension based integration.

This list is the result of a comprehensive research on sugarforge.com (done on 2009-12-02) forthe most helpful and most interesting plugins from sugarforge.org that are helpful for the purposes of a SugarCRM deployment that I created  at that time. Especially, I searched how to realize the feature to to see for multiple contacts at once by what campaigns they are covered; however, no extension provided that feature directly at this time.

Hint: the best way to search for extensions is this list. If you search for Open Source extensions only, search in that list by licence.

1. ZuckerSync for OpenEMM. Perhaps useful, if OpenEMM is used as the E-Mail sending engine. Or as a template to create a sync extension for another e-mail sending software.
2. AJEXA iMarketing. For better result tracking of campaigns; for creating nice HTML mails from within SugarCRM.
3. Power Prospecting. Adds the option to add contacts to target lists directly from the contacts component. This is recommended for more comfortable creation of contact lists [source]. Could be extended to show the target lists of contacts in contacts lists, but we’d need to show the individual mails … or don’t we?
4. ZuckerReports. Might be useful for creating lists of contacts and showing at the same time to which campaigns they belong.
5. SynoReports. Reports that can include custom SQL queries and output to lists in SugarCRM. Might be useful for creating lists of contacts and showing at the same time to which campaigns they belong.
6. Funambol-SugarCRM Connector. For using address data etc. from Sugar CRM on mobile devices, like the IPhone. Probably also good for syncing with an OS X address book.
7. CarouselCRM. A native client for SugarCRM, with offline mode, also adding sync features for Skype, Word etc..
8. Custom Import Templates. Importing addresses from XML and the like.
9. AutoProspects. Updating e-mail target lists semi-automatically.
10. StoreIt. Automatically saves BCC’ed or forwarded e-mails to the respective customer records. Perhaps not needed as SugarCRM now includes full integration with e-mailing.
11. Talend Open Studio. Eclipse RCP based application for migrating data to SugarCRM, syncing with other databases and the like.
12. ModuleBuilder. The simplest way of creating a new extension for SugarCRM. But probably already included in SugarCRM CE 5.5 RC.
13. German address format. Tool available as country_address_ger_0-5b.zip, indexed at the iscon download list. Not recommended because of a major problem:
    • Installation is done as a normal SugarCRM module in “Admin -> Module administration”.
    • In its manifest.php it says that it works for SugarCRM CE 5.2*. Installing on version 5.5 did not work (the “country” field in address forms was a dropdown field without values).
    • No simple workaround or fix was found for this problem. The problem seems not to be related to the mod_suphp permissions problems (as the workaround to use “chmod -R a+r,o+X *” in the httpdocs/ directory after installing the module and after populating cache/ by first calling it does cure all permissions errors in the access log, but does not cure the problem of the empty select box).
    • More interesting links around this problem:
      sugercrm.com thread 180006
      SugarCRM wiki: Converting all country fields to dropdowns
      sugercrm.com thread 51347
      sugarcrm.com thread 40137
    • Note that, after uninstalling the module, you need to clear the cache yourself to no longer have the contact form rendered according to that module. Reloading the page alone does not help, instead use:
      rm -R cache/modules/Contacts/*

1. Official, English documentation: SugarCRM CE documentation. (There is also the SugarDocs project on SugarForge, but everything on there is outdated, and the official docs were moved to the address mentioned.)
2. German SugarCRM 5.5 manual by iscon. (iscon created that manual once for version 5.0 and offered it for free on their website [source], but it seems that now they think this is something to earn money.) This is available in two versions:
   1. For 30 EUR as a PDF file: “Sugar Handbuch 5.5 deutsch – inklusive Admin Teil“.
   2. For 30 EUR as a printed book: Robert Laussegger: “SugarCRM – Das CE Handbuch”; BOD Verlag; ISBN: 978-3839109458 [Amazon link]
3. There are plenty more of English books on SugarCRM but it seems, no other German ones.

1. Melden Sie sich bei SugarCRM an. Im Folgenden wird davon ausgegangen, dass Sie dabei unter »Options« Deutsch als Sprache für die Benutzerschnittstelle ausgewählt haben.
2. Klicken Sie rechts oben auf »Admin«, um in den Administrationsbereich zu gelangen.
3. Klicken Sie im Bereich »Entwickler Werkzeuge« auf »Auswahllisten bearbeiten«.
4. Im zentralen Bereich erscheint nun eine Liste der im CRM vorhandenen Auswahllisten. Klicken Sie dort auf »account_type_dom« um die Werte des Felds »Typ« zu bearbeiten, oder auf »industry_dom« um die Werte des Felds »Branche« zu bearbeiten.
5. Im zentralen Bereich erscheint nun ein Tab »Auswahlliste bearbeiten«, in dem Sie die verfügbaren Werte des gewählten Feldes bearbeiten können. Stellen Sie sicher, dass hier »Sprache: Deutsch« ausgewählt ist.
6. Um einen möglichen Wert hinzuzufügen, tragen Sie einen englischen (intern verwendeten) Elementnamen und die zugehörige deutsche Anzeigebezeichnung in die entsprechenden Textfelder ein und klicken auf »Hinzufügen«.
7. Um einen der verfügbaren Werte zu löschen, klicken Sie auf das Mülleimer-Symbol rechts im entsprechenden Listenelement. Das Listenelement wird danach grau und durchgestrichen dargestellt.
8. Um den Anzeigename eines Wertes zu ändern, klicken Sie auf das Stift-Symbol rechts im entsprechenden Listenelement. Gegenüber dem Löschen des Elements und Erzeugung eines anderen hat dies den Vorteil, dass Datensätze die diesen Wert aktuell verwenden ihn nicht verlieren, sondern lediglich so aktualisiert werden dass sie mit dem neuen Anzeigenamen des Elements dargestellt werden.
9. Klicken Sie abschließend unbedingt auf »Speichern«, um Ihre Änderungen an den Server zu übertragen.

Adjust permissions so that the web server (running as www-data) can read and write what it wants:

chmod -R 777 cache/;
chmod 777 custom/;
chmod 777 data/;
chmod 777 data/upload/;
chmod -R 777 modules/;

If auto-checking for update is enabled and also SAFE_MODE, use this workaround to prevent SugarCRM to create that directory with www-data:www-data ownerhip:

mkdir cache/upload/upgrades/;
chown matthias:psacln cache/upload/upgrades/;
chmod a+w cache/upload/upgrades/;

The setup was this: a domain example.com, registered at Domaindiscount24 (dd24.net) as the DNS hoster, and set up there so that there was an “IN A” record pointing to the Hostgator server’s IP address, and a “IN MX” record containing “10 example.com” (with 10 being the priority). On the Hostgator server, the example.com domain was registered for webspace (and this worked), and a mail forwarder to another domain (also hosted on Hostgator) was set up, but no e-mail accounts for example.com.

The exact same style of setup worked for e-mail for another domain, also at DD24 and Hostgator, for which webspace and a mail account was set up.

However, in this case, the mail forwarder for the example.com address did not work: mails did not get forwarded, except if they were sent from another domain that was hosted on the same Hostgator server. The mails also did not appear in the customer-wide spam folder, and no error message was sent back to the sender (which effectually means that the mail was lost). It seems also that sometimes, the forwarding is successful, for whatever reason.

The error might be: before forwarding, according to the DD24 entry, the mailserver of example.com has to be contacted. But there might be a bug on Hostgator’s server configuration that only creates such a server when a mail account (not a mail forwarder) for this domain is created. The strange thing is however, that the mail senders do not receive errors back when sending to example.com addresses. Which might be because the Hostgator server accepts such mails in a kind of catchall address, but cannot distribute them to the different customers hosted on that server as it does not know what domain belongs to what customer.

The workaround for this error (tested successfully) is to set up e-mail forwarding (at best, with a wildcard) directly at the DNS hoster (here, DD24). This change takes effect on DD24 in a few minutes, but because of the DNS cache times it propagates for use in normal mail software only in 4-7 days. You can see that by the difference in the output of the following commands:

dig example.com MX
dig @ns1.domaindiscount24.net example.com MX

If both contain something lilke “example.com. 28800 IN MX 10 mailfw3.dd24.net.” (and a second line like it), the change is complete. This happened in the current case some 4-6 hours after doing the change in the DD24 admin area.
This however leaves one problem untreated: when sending a message to example.com from a domain that is also hosted on the exact same Hostgator server as example.com, the SMTP agent on that server that has to send this message seems to think that it is also the MX server for example.com, does not find the specified target mailbox, and subsequently returns an error message to the sender: “Mail delivery failed: returning message to sender. A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed: mail@example.com No Such User Here.” This is again a DNS routing bug on the Hostgator servers, because a MX record must be used if it is present, as it is here, according to RFC 5321 sec. 5 (en.wikipedia.org/wiki/MX_record#History_of_fallback_to_A). The workaround is to go to the Hostgator e-mail administration tool and re-enable a mail forwarder *@example.com to a target mail address, which will take effect only for mails dispatched by the SMTP agent on that server.

This last step of adding an e-mail domain forwarder (from *@example.com to a target address) has the added advantage that using an example.com mail address as the From address becomes now possible, whereas else, the SMTP client on the Hostgator server would reject sending such mails.

Task

I had to run existing ActionScript code on a headless Linux server and decided to do it by running an AIR application with the Xvfb virtual X server, as reasoned for in my article “How to run ActionScript in headless mode (on Linux without X server)?“.

Problem

I did not think that running an AIR application on a headless server would be that large a problem. Here is why it is:

• The normal Adobe AIR 1.5 runtime installer is a GUI-based installer, no RPM oder DEB packages are available.
• The normal process of installing an AIR application is also a GUI-based process, so not apt for a Linux headless server.
• AIR applications itself are GUI-based, always needing an X server. See more on that in this article already linked above.

Discussion

In theory, installing the AIR 1.5 runtime and the AIR application would be possible via VNC or some Xvfb hacking to enable a remote desktop. In practice, I searched for a better solution.

There are two options; first, the headless installation of Adobe AIR 1.5 Runtime if you grab the version you get after applying to distribute AIR. Second, Adobe AIR 2.0 (in beta as of 2010-05-10) offers installation packages for various Linux systems. You can download Adobe AIR 2 Runtime beta Linux packages from Adobe labs. This enables headless installation with ease. The exception is if you are on a 64bit Linux system, in which case you need to follow along the well-done article “Install Adobe AIR 2 on 64-bit Linux distributions” from Adobe.

However, this approach faces another problem: AIR applications normally come in .air files, and these files cannot be installed on a headless server with a AIR Runtime – normally. The only exception is when using a special installer made available by Adobe after successfully applying for a AIR Runtime redistribution licence [source]. You can apply to distribute AIR (as already linked above). The bad thing is that, at least currently (2010-05-10), a redistribution installer is not available for Linux, and it is not allowed to modify another redistribution installer for that purpose; see the Adobe AIR Runtime distribution FAQ on “Can I distribute the Adobe AIR Runtime on an operating system if a version specific to that OS is not provided?“. So the “Adobe AIR Application Installer -silent file.air” option is not possible on Linux. (If you try that with the standard AIR installer, it says “install failed (see log)”, but even after enabling AIR logging, the log stays empty.)

The solution that I found is to deploy not the .air file but the .swf file and application .xml file that are generated during development in the bin/ output folder. These can be launched with the Adobe debug launcher (the adl command). And adl comes within the Adobe AIR SDK, which is installed by just unpacking, very apt for a headless server. Note: you do not need to install the Flex SDK also if you just want to run an AIR application this way.

By deploying the compiler output directly, we also get around the process of creating the and signing .air installation file. In case you need to do that anyway:

• First try out the FlexBuilder integrated wizard along the Adobe instructions “Creating your first Flex AIR application in Flash Builder or Flex Builder: Package, sign, and run your AIR application“.
• If that fails and you are given a strange error code, have a look at the ADT error messages.
• If that didn’t help either, follow instead the Adobe instructions “Creating your first AIR application with the Flex SDK: Create the AIR installation file“. That finally worked for me.

The last problem is that running an AIR application on a headless server needs an X server in any case. We want to use the Xvfb virtual X server, as already reasoned for in my article “How to run ActionScript in headless mode (on Linux without X server)?“. Brett Adam designed and shared a simple Xvfb wrapper for running an AIR application with Xvfb. It turned out however that the program xvfb-run, coming with Xvfb at least in the Ubuntu 9.10 package, does exactly the same job and offers also more options; so we stick with that.

Solution

Here is a combined list of instructions how to get all this to work, according to the decisions outlined in the discussion section:

1. Download the Adobe AIR SDK to your server. Download the Adobe AIR SDK manually and upload to your server, or better use:

   wget http://airdownload.adobe.com/air/lin/download/latest/AdobeAIRSDK.tbz2;

2. Install Xvfb. On Ubuntu systems, install the packages xvfb and xauth for that.
3. Install the Adobe AIR SDK on your server:

   mkdir /usr/local/share/applications/air-sdk-1.5;
   cd /usr/local/share/applications/air-sdk-1.5;
   tar xjvf AdobeAIRSDK.tbz2;
   ln -s /usr/local/share/applications/adobe-air-sdk-1.5/bin/adl /usr/local/bin/;
   ln -s /usr/local/share/applications/adobe-air-sdk-1.5/bin/adt /usr/local/bin/;

4. Upload your AIR application to your server (just the .swf and .xml file in you project’s bin/ folder).
5. Launch you application with xvfb-run:

   xvfb-run -e log.txt --auth-file Xauth --server-num=99 adl Application-app.xml

6. If you need to run your applications with arguments, do it like this:

   xvfb-run -e log.txt --auth-file Xauth --server-num=99 adl Application-app.xml -- --arg val

7. If you need to keep Xvfb running (e.g. because you need to start the AIR application many times and want to get rid of the 3s delay to start Xvfb every time to improve performance), here is a technique for that. It is re-using xvfb-run, letting it run a command that never returns, and then lets other applications connect to the started X server:

   xvfb-run -e log.txt --auth-file Xauth --server-num=99 sleep 1000d &;
   DISPLAY=:99 XAUTHORITY=Xauth adl Application-app.xml -- --arg val

This task is quite strange: I needed to find a way how to execute existing ActionScript code on a headless Linux server. A scenario like this can also happen if you need to develop an automated test environment for you Flash / Flex or AIR applications. You cannot run either Flash SWF files or AIR applications on a headless server, as both needs always graphics output. Even in the case of an AIR application that shows window at all. In Linux this means, it needs a running X server. Otherwise, an AIR application throws the error “Gtk-Warning **: cannot open display:”.

There are multiple discussions in the Internet how to solve this (e.g. here and also here in the Adobe forums), and they agree that the only solution that is currently feasible is to use Xvfb for mimicking an Xserver (or alternatively, the same approach with VNC). But here are all the alternatives I looked into, this working one first:

Xvfb to mimic an X server

Xvfb is a “virtual” X server, granting an X server interface to application, but doing all the calculations in memory. You do not need and physical input devices or screens attached to the machine for this.

There is one problem with the Xvfb solution, however: “which is that AIR is not currently recommended by Adobe for headless server-like applications. As I understand it, there could be cases where the runtime popped up a confirmation dialog, and some things about the app might not work correctly until you remoted into the server to dismiss the dialog.” [source]. See also a comparable statement here.

We can get around this by designing the AIR application so that a new process is started for every request (while the X server stays running all the time, and the AIR processes connect and disconnect with it). This has some performance penalty, but works around the problem that a server-like (port listening) AIR application has with the above “confirm the popup” thing.

The task to deploy and run an AIR application this way on a headless server is a project of its own, and I have written about it separately.

Tamarin to run ActionScript bytecode

This was the other alternative proposed when the question popped up in th Adobe forums here. Tamarin is a ECMAScript virtual machine that can run ActionScript byte code.

Now the restriction is that only ActionScript code could be executed server-side. Which means that code that depends on the Flash, Flex and AIR runtime libraries could not be executed, as these runtime libraries are native and closed source, not included in Tamarin. So the code that can be executed in Tamarin is quite limited and useless, as there would be no way to communicate with its environment. To solve this, some ideas come to the mind:

• There would be the option to create own ActionScript classes with a native implementation, adding them to Tamarin, which then would enable the required features for communicating with other pieces of software, like writing files etc..
• In extension of this, perhaps the Merapi Java / ActionScript bridge could be used together with Tamarin.
• Perhaps there is the option to extract the runtime libraries from Flash player or the AIR installation, but this is quite heavy hacking, and not apt for redistribution because of Adobe licencing restrictions [source]. Probably it is enough to not call any part of the library that depends on graphics output (as such calls result in errors without X), but perhaps it would be required to only extract those part of the runtime libraries that do not depend on graphics output (as we want to get around this very requirement here).

Custom AIR launcher

This is some serious AIR hacking, and not apt for redistribution because of Adobe licencing restrictions [source]. It might be possible to create a new AIR launcher that includes the AIR runtime DLL as an in-process shared library (outlined here). But again, exactly this runtime DLL would still need a running X server. So again, probably it is enough to not call any part of the library that depends on graphics output (as such calls result in errors without X), but perhaps it would be required to only extract those part of the runtime libraries that do not depend on graphics output (as we want to get around this very requirement here). At least the dependency of the launcher from X would be removed that way (guessing that it is the launcher that checks if X is running).

The headless Flash player Ichabod together with Merapi

Merapi is not only able to connect Java with AIR applications, but also with Flash / Flex applications that run in the Flash player. Together with the headless Flash player, this would be a quite elegant solution.

The problem is, the headless Flash player is not publicly available. It is called Ichabod and reportedly used by Google to index Flash content [source], but apart from this and perhaps some very few other customers, nobody has access to it. There is a feature request for a headless Flash player here, but it is still open. See also this article about the Ichabod rumors.

As the normal Flash player needs also an X server, there is no way to resolve that dependency here. Merapi is of no additional use here.

haXe to run converted ActionScript code

The programming language haXe is quite similar to ActionScript, and cam compile to native code, among other things. So that it is possible to convert ActionScript applications to haXe applications, which run without a dependency on X.

However, if you are including large ActionScript libraries, this conversion process takes quite some effort. For example, it took quite a time for Away3D to release the haXe version of Away3D Lite, and it compiles currently only to Flash (of no use here) and experimentally to JavaScript (also of no use here).