=====================================
20140213 (Thursday, 13 February 2014)
=====================================


Still problems with Java applets
--------------------------------

Gerd cannot run `test-eidreader
<http://test-eidreader.lino-framework.org/>`_ after their upgrade to
7u51, he gets::

  uncaught exception: Liveconnect call for Applet ID 1 is not allowed in this JVM instance

Google then leads me to a page `LiveConnect changes in 7u45
<https://blogs.oracle.com/java-platform-group/entry/liveconnect_changes_in_7u45>`_,
of which I understand only fragments, and which has comments like:

- "Adding ``Caller-Allowable-Codebase: *`` to the JAR's manifest file
  isn't making the error go away. Any ideas?"

- "Please keep 'improving' the applet experience Oracle, each time you
  'improve' things it makes it easier for me to justify removing applets
  from our solution. This 'fix' seems incredibly poorly thought out,
  badly/untested and yet another nail in the applet/webstart coffin."

- "Oracle is really making it difficult for end users to run Java
  applets. The last couple of years have been a slow but steady death
  for applets."

All this sounds very frightening. Yes of course users are frustrated
when everything is changing and unstable. And yes of course we don't
know Oracle's motivations for these changes.  But there is still hope
that Oracle are just struggling, that they will manage to get it
stable one day. Java applets continue to be the best implementation of
a platform-independent environment for web applications. So stop
moaning and continue to swim.

So I invited Gerd to run a next test: let's try with a
`Caller-Allowable-Codebase
<http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/security/manifest.html#app_library>`_
attribute in my `Manifest.txt` file::

  Caller-Allowable-Codebase: *

(The docs say that "This attribute is not needed if the JAR file for
the RIA is in the same location as the JNLP file or HTML page that
starts the RIA", but the comments and our previous experiences
indicate that statements of this kind aren't reliable).

To protect us from problems due to unrecognized caching, I changed the
initialization message to::

   System.err.println("EIDReader version 20140213 initialized");

I asked Gerd to test this. And then I went to sleep without much hope.
I did not test this myself because each test costs me a few minutes (I
must log into a virtual client machine, locking my own machine during
this time) and when it fails I cannot even see the Java console.

And a few hours later, while I slept, came the unexpected good news:
the above **was** the reason!  I worte to Gerd:

    Insgesamt würde ich die Situation wie folgt zusammenfassen:

    Zum Einlesen der eID-Karten und zum Bereitstellen von editierbaren
    Dokumenten (zur Zeit nur Lebensläufe, später auch andere
    Bescheinigungen) braucht Lino eine Technologie namens Java.

    Java, eine ursprünglich freie Software, wird seit Jahren durch
    Oracle (zuvor Sun) benutzt, um ein Monopol aufzubauen. Das macht
    sich bemerkbar in unzähligen Problemen wegen ständiger Änderungen
    im Sicherheitsmechanismus. Bei jedem "Upgrade" hat man neue
    Überraschungen.  Unter Experten ist das allgemein bekannt und wird
    viel bejammert und angeprangert.

    Aber rein theoretisch ist Java der richtige Weg, um die
    o.g. Funktionalitäten zu implementieren. Ob das in der Praxis auch
    so bleiben wird, kann heute niemand sagen. Auf Oracles Pläne und
    weltweite Entwicklungen ist unser Einfluss eher gering. Wir halten
    die Augen offen nach Alternativen, aber uns ist momentan kein
    vertretbarer Kandidat bekannt.

    Deshalb: insgesamt bejahen wir unsere Entscheidung, weiterhin mit
    Java zu arbeiten. Wir hoffen, dass die problematische Phase in
    Oracles Implementierung bald vorbei ist und lernen immer besser,
    wie man solche Probleme möglichst schnell in den Griff kriegt.

I verified that we can exclude side effects due to "changed
circumstances" (a usual phenomen when you work with Java) by (1)
reproducing myself that it works, (2) removing the line, updating the
site and verifying that it *fails* and (3) restoring the line again
and verifying that it works again.


Attestations
------------

:srcref:`docs/tickets/93`

.. currentmodule:: lino.modlib.attestations

When creating an :class:`Attestation` by double clicking in
:class:`AttestationsByProject`, then the `project` field gets filled
automatically, but we also want to set the `owner` field to
the project.

`lino_welfare.migrate` now writes a file `migrate_from_1_1_10.py`,
intended to get executed after the real migration. This script renames
the `.rtf` files generated per `notes.Note` of type "Lebenslauf" so
that Lino finds them back now that they are an
`attestations.Attestation`.


Blogging
--------

:srcref:`docs/tickets/88`

I stumbled over an article for which I'd like to write a blog entry,
mostly in order to find it back when I need it in 3 years or so.
I tried to do this on my shiny new FSFE WordPress blog.
`Here it is <http://blogs.fsfe.org/luc.saffre/2014/02/10>`_.
But I perceived it as a pain to do this. 
Switching between Emacs and the WordPress web interface is a pain.
I want to blog in restructuredText because that's how I am used 
to write down my thoughts.
Oho, Luis Artola had similar problems,
and he wrote a tool called `restblog
<http://restblog.sourceforge.net/>`_
Will this be for me?

My first spontaneous reaction: Cool! But I want one single file per
day with possibly several posts (possibly published to different blog
servers).