iPhone Myst update 1.1.3 available

The long awaited iPhone Myst update 1.1.3 has finally been approoved and is available on the AppStore. Besides enhancements (in-game browser, etc.) and various fixes, the description lists sound and music bugs fixes.

Navigon MobileNavigator France only

A France only version of Navigon MobileNavigator is now available at the AppStore. The install size is reduced to 340 Mb (from 1,65 Gb for the Europe version) and it is priced 49,99 euros until June, 30 (69,99 euros after). The Europe version (includes Great Britain and Irlande) is provided at 74,99 euros until June, 30. It is useful for countries like Greece that use another alphabet, and is cheaper for frequent travellers (as it avoids buying a lot more maps).
We don’t know yet if an upgrade from France to Europe version will be provided. The level of details for other european countries than France isn’t precised (we reach the 1,65 Gb for only 5 countries of about France size, and the Europe version includes more than 30 countries).

Rick Dangerous on iPhone

An iPhone version of the famous Rick Dangerous platform game is available at the AppStore (1,99$). It features new graphics (more colored) and musics, and introductory sequences. Controls use a virtual D-Pad (no full screen/landscape/hud style controls for now).
We can probably also expect Rick Dangerous II soon.

Arturia : The 10 Year Suite

For its 10th anniversary, Arturia provides The 10 Year Suite, a bundle composed of its 8 modeling softwares : Minimoog V, Moog Modular V, CS-80V, ARP2600 V, Jupiter-8V, Prophet V/Prophet VS, Brass, and Analog Factory. It is priced 699$ only. The songAnalog Factory was based on sounds from the Analog Factory demo.

MJ Style : 1996-2009

In early 1996 I composed MJ Style, a song inspired by famous MJ feets dance and rhythm.

I now know he will never get a chance to listen to this, not in that land.

The day before I had a significant blood pressure drop that lasted half a week, and two weeks before I realized that he would be the most suited for singing on my songs and that I should probably find a way to contact him (such thing I wouldn’t ever have attempted before).

I also rearranged dozens of its songs in the 90’s, first using the JV880, and later the XV.

Google AppEngine limitations / workarounds

Here are some limitations to consider when we plan using AppEngine. They are most likely due to clouds constraints and consistent performance concern. We can read a compatibility list of various J2EE frameworks and supported Java APIs.

1000 files limit
Each application is limited to 1000 files. Then when using Cappuccino we have to use Press tool (with flatten option – to be tested with 0.71 version as it was broken in 0.70 beta) or remove the .j files (keep only the .sj). For CP2JavaWS, images resources from unused components were also removed (load time should be however better using Press).
As the concept of physical machine is gone with clouds computing, we cannot write in files, and we can only read files in WEB-INF (or accessibles through the classloader).

1000 results limit / limited offset for requests
For performance concerns, requests results are limited to 1000 records. Moreover the offset cannot be higher (requests return 0 records when the offset reaches the 1000th position). Then we cannot browse a thousands of lines table with limit(offset, count) if not using a filter/condition.
We could still add a criteria on the index to fetch records in multiple parts (for each thousand step). However this would only work if we are sorting by the index (wouldn’t work if sorting by another column). It is the same if using two requests (one for retrievinig the indexes and another using selection where index in (index range) limit count), as the first request result will be limited. Same problem if we use a temporary sort table (the result from the select request used to retrieve the data to insert is limited), moreover that solution requires to compute again the temporary table if the sort criteria (or condition criterias) vary.
One solution would be to define a special key (see Python section Queries on Keys, _key_), in memory managed and without read limit (same section for Java/JDO doesn’t however include these informations). It would require to be able to modify dynamically this key (as it depends from the sort column), or to define for each sort column an additional column (setted alongwith each insert), composed with the sort column value and index value. We could then add to the request a _key_>previous limit value criteria (value of the composite column fot the last element retrieved during the last 1000 elements fetch). Adding a criteria on the primary key wouldn’t work if using another sort column, as the criteria applies before sorting (that problem is worked around if the criteria uses the composite column that corresponds to the sort column).
We can however assume that search criterias have to be refined/tighten if more than 1000 results are expected.

Mapping limitation / caches synchronization
Hibernate isn’t supported as it instancies statically a UUID generator, using inetAddress class (is among the restricted/unsupported APIs by AppEngine, as well as other machine related instructions : threads, etc.) Then a modified version of an Hibernate class is provided in CP2JavaWS (uses code from JUG framework instead).
The demo of CP2JavaWS uses an HSQLDB in-memory database to easier the example install (no databse server to create), and table and initial data are created at launch time (from a context listener). The values of the third column (age) are generated randomly, in order to allow testing of sort feature. Then these values can change depending the timeframe we access the application (as these values are in memory, they are different from an application instance to another). That isn’t a problem however for that demo (no persistance required).
We could configure an url to a database server, however it would have to be hosted elsewhere (if not datastore). And we cannot also use a local file to persist the database (only read allowed).

The main concern is memory synchronization between cloud nodes (application instances), as mapping solutions use two objects caches. The first level cache (one per persistanceManager/MappingSession – typically per user session) allows to compare a working object copy with the corresponding original (fieldLocking), and second level cache (one per persistanceManagerFactory/SessionFactory) allows to compare orignal object from persistanceManagers with current corresponding objects in the central cache (that is necessary for optimistic locking. Direct access – back door – to the database without passing through the persistanceManagerFactory – that is generally retrieved from JNDI – is forbidden, in order to keep integrity).

The GAE datastore is based on the DataNucleus mapping framework (implements JDO and JPA). By default the level 2 cache is off in DataNucleus, however by activating it (through settings) we can choose among various implementations : EHCache, Oracle Coherence, memcached, etc. In that list only Oracle Coherence and memcached allow work in a distributed environment (second level cache replication) – also the case for more recent versions of EHCache. Thanks to the plugin architecture in DataNucleus we can develop extensions to use another cache framework that manages distributed mode : JBoss cache, OSCache, Terracotta, etc.
The Google datastore uses a proprietary implementation of JCache specification (JSR107) to allow a distributed mode, and manages replication automatically. DataNucleus provides a manual API to manage datastores replication (for example the JDOReplicationManager to synchronize PersistanceManagerFactory). The AppEngine SDK also provides Memcache APIs, to manage (manually) replication of custom objects if needed.

Replacing DataNucleus with Hibernate (can use distributed caches like JBossCache, OSCache, Coherence and more recent versions of EHCache) in a GAE application would require to have hooks into the replication process (synchronize the HibernateSessionFactory). The distributed caches configuration (static) would however require to know exactly the nodes hosts, and GAE doesn’t provide such information.

Finally we are tied with the Google datastore, with the following restrictions (do not come from Datanucleus limitations) : no aggregate requests, no polymorphic requests, limited filters, limited joins, limited many-to-many relations support, etc.
As BigTable isn’t relational, JDO looks interesting as it isn’t restricted to relational datastores (contrary to JPA). DataNucleus manages various datastore types, and an extension (plugin) to BigTable had to be developed by Google (notably to manage access through JPA interface). Despite the GAE datastore being at a higher level of abstraction than BigTable, some limitations seem directly tied with that implementation choice, whose goal is to provide consistent response time whatever the request (thus the above limitations).

No support for SOAP webservices
This shouldn’t be a problem as recent RDA solutions (GWT and Cappuccino/CP2JavaWS) use JSON (enhanced with proprietary fields).

Inter-applications communication
Applications have to use URL Fetch APIs from AppEngine SDK to communicate.

Tools and WTP integration
The Eclipse plugin allows to create a web project (with AppEngine webapp configuration file, and required jars – have to be added manually to the buildpath), but doesn’t provide integration with WTP (and no mean to stop the AppEngine server once stared – have to use WTP stop button). We can in fact deploy an AppEngine project from a WTP project, by renaming WebContent to war, and by adding the appengine-web.xml file to WEB-INF folder of the WTP project. However we then haven’t support for classes enhancement (required for the datastore JDO and JPA implementations). We could probably add this automatic task by adding the appropriate builder in the .project file.
The enhancement step required for the mapping adds to the previous constraint of client code generation if using GWT. Some JDO solutions like LIDO still allowed to remove the enhancement step if needed (leading however to some performance hit as expected).

Cappuccino 0.71 and controls demo

Cappuccino 0.71 RC1 has been available for a few days. It brings these fixes/changes and we can now access to an online demo of the whole controls, notably the new Segmented Control type. The final release should be online very soon.

Java update for Leopard

A new update to Java 6, 5 and 1.4.2 is available for Leopard (Java 6 however only supports Intel macs). The updated versions are then 1.6.0_13, 1.5.0_19, and 1.4.2_21.

VSL Vienna Imperial available

VSL presents Vienna Imperial, a Bosendorder Imperial 290-755 piano library that includes 500 Gb of samples (100 velocity levels / 1200 samples per note – includes multiple length release trails) ! The samples (24 bits/44,1 Khz) are compressed at install time (lossless) to only require 50 Gb. A new player is provided (features a convolution reverb). An Intel Core Duo mac with Leopard is required, as well as 1,5 Gb available ram. Audio demos are available. It is priced 875$.

Yamaha S90 XS / S70 XS

Yamaha presented the S90 and S70 XS, evolutions of the S90, with 88 keys (S90 XS) or 76 keys (S70 XS). They use the same audio engine as the Motif XS, and include 142Mb additional new piano samples from a Yamaha S6 (456 Mb total rom).

CP2JavaWS 0.72 : fixes / AppEngine support – online demo

A new version of CP2JavaWS is available at sourceforge :

Note : now uses json2lib stringify and parse methods from latest Cappuccino main branch (and future 0.71 version). Then it does not work for version 0.7 (or you should replace these methods manually by these from CPValue). These two new methods should lead to general better performance.

– Modified server-side demo HabilitationServiceImpl to return true for the 
genericDAOService methods.

– CP2JavaWSEndpoint init had a bug with testing presence of sameDomain 
argument : replaced if(aSameDomain) with if (aSameDomain!=nil).

– CP2JavaWSTableViewDelegate : in sendSynchRequest, added the test for 
sameDomain (was ok for sendAsynchRequest) to use JSONP mode if not same 
domain.

– Modified hibernate config .hbm file to use assigned generator for the id, as AppEngine does not provides the InetAddress class.
However Hibernate’s SessionFactoryImpl still owns a static field of type UUIDHexGenerator that is always initialized, and that extends AbstractUUIDGenerator, whose uses InetAddress in its static init part.
Then had to redefine AbstractUUIDGenerator (included in same original package name in the demo project’s src folder) : when deploying to AppEngine we have to comment the line that uses InetAddress and uncomment the line that uses a random generated address (based on JUG project, also licenced under LGPL).

A working demo is now available on AppEngine (same code as the included webapp example except the endpoint’s url and use of the random generated address in the redefined AbstractUUIDGenerator class) :

http://cp2javaws.appspot.com

(tested on Safari 4 and Firefox 3.0.x. Is ways faster on Safari, however performance should be improved with upcoming Firefox 3.5 release).

CP2JavaWS 0.71 : generic remote DAO service / CPTableView

A new version of CP2JavaWS is available at sourceforge :

Note : now uses json2lib stringify and parse methods from latest Cappuccino main branch (and future 0.71 version). Then it does not work for version 0.7 (or you should replace these methods manually by these from CPValue).
These two new methods should lead to general better performance.

– fixed a cache problem : now if an asynchronous request was pending before a cache fault, its return is ignored (as the state isn’t the same as originally expected after a cache fault).

– the sorting code now works properly (as soon as headers and CPSortDescriptors are added to CPTableView). It can still be tested by modifying the init value for currentSortDescriptorsStr in CP2JavaWSTableViewDelegate (see commented code). The reference is now the position in the table, and limit(first, length) requests are used.

– added a new generic service, GenericMasterDetailDAOService, that manages retrieving of elements for any CP class, using Hibernate. It then avoids having to define a DAO service (the previous mode is still available, for custom management or non-database datastores).

To use the new mode, pass the table elements CP class name when creating the CP2JavaWSTableViewDelegate, instead size and read method names (that are then generic).