Planète GTLL

[Compatible One] CompatibleOne 2nd Hands On Session in Paris

2012-06-13T15:14:21Z

Significant progress have been made since January'session. It is time now for a new "Hands On" session. This session will be the opportunity to answer all the questions you may have concerning usage of CompatibleOne. You will be able to to manipulate CompatibleOne platform with the help and support of the developers themselves. And naturally these sessions will be interactive and will take place

[Compatible One] CompatibleOne at the Green IT & Cloud Aristote seminar

2012-06-05T10:33:23Z

Maxime Morel et Julien Carpentier (INRIA - ENS Lyon) will present the CompatibleOne approach to energy efficiency of Cloud infrastructures at the Green IT & Cloud Aristote seminar.
The detailed program of the seminar can be found at http://www.association-aristote.fr/doku.php/public/seminaires/seminaire-2012-06-05

[Compatible One] CompatibleOne presentation at the OW2 Berlin Day

2012-05-29T10:35:25Z

Cedric Thomas will present "CompatibleOne: the Open Source Cloud Broker: architecture overview” at the OW2 Berlin Day.
More details at http://www.ow2.org/Events/OW2_Berlin_Day_2012

[Nuxeo Blogs] [dev] [Q&A Friday] How binaries are physically in the file system

2012-05-25T14:46:48Z

How are binaries stored in Nuxeo?

Today we have a question from systemz who asks where Nuxeo binaries are physically stored in the file system.

The class that takes care of binary storage is the BinaryManager. There are several implementations (BinaryManagerClient, DefaultBinaryManager, SQLBinaryManager, XORBinaryManager). There is also one for Amazon S3 on our Marketplace. It offers the option of storing binaries in an Amazon S3 bucket.

The default implementation is DefaultBinaryManager. Its goal is to compute the digest of the binary and store it on the server’s file system accordingly. Let’s say, for instance, that our file has the following digest: a75badefeb96972667306ac8f696143b

Its location will be nuxeo.data.dir/binaries/data/a7/5b/a75badefeb96972667306ac8f696143b where:

nuxeo.data.dir is the folder corresponding to the nuxeo.data.dir property from nuxeo.conf
binaries is the path defined in the binaryManager contribution
data is the hierarchy with the actual binaries in subdirectories
a7 is a folder named after the two first characters of the digest
5b is a folder named after the third and fourth characters of the digest
a75badefeb96972667306ac8f696143b is the file named after the digest

You can configure the depth of the folders and the key algorithm used to compute the digest. The default algorithm is md5 and the default depth is 2.

To change the implementation of your BinaryManager, as usual you need to contribute to an extension point:

  <extension target="org.nuxeo.ecm.core.repository.RepositoryService"
    point="repository">
    ...
    <repository name="default" factory="...">
      <repository name="default">
        <binaryManager class="org.nuxeo.ecm.core.storage.sql.S3BinaryManager"
         path="binaries"/>
        ...
      </repository>
    </repository>
    ...
  </extension>

If you want more details about this I suggest you read the installation documentation for the Amazon S3 Online Storage.

So, as you can see, it’s really hard to identify binaries without using the Nuxeo API. I would discourage anyone from doing that. But in case you have to, here are a couple of suggestions on how to retrieve the digest computed by the binary store.

Don’t mistake this with the Blob digest metadata. This digest is different from the one computed by the binary store. It’s used by the unicity check API.

To retrieve this digest, you have to use the Binary object, available only through an SQLBlob.

Again, this is a real pain, and I really encourage you to use the usual Nuxeo API :-)

Thanks for reading, see ya’ on Monday!

[Adacore] The syntax tree is now dynamic

2012-05-25T00:00:00Z

The syntax tree has been made dynamic allowing analysis of programs containing more than 3,200,000 productions.

[OpenWide] ALM et Open Source – Petit Déjeuner le 19 juin 2012

2012-05-24T15:23:07Z

Inscrivez-vous gratuitement au petit déjeuner
le mardi 19 juin 2012 de 8h30 à 11h chez
Open Wide Technologies
23-27 rue Daviel – 75013 Paris.

Malgré un environnement de développement Java devenu plus mature, déployer une chaîne d’intégration continue, organiser une gestion des tests unitaires, sécuriser le suivi des versions ou assurer une mesure continue de la qualité restent des opérations complexes.

Plus largement, les solutions d’ALM (Application Lifecycle Management) ont pour vocation de proposer un processus continu de gestion du cycle de vie d’une application en terme de gouvernance, de réalisation et de maintenance.

Les solutions qui proposent d’outiller ce processus sont souvent complexes et coûteuses à mettre en œuvre. Au cours de ce petit déjeuner, nous vous présenterons la forge de développement Improve Factory, une solution d’ALM simple, légère et économique reposant sur des solutions open source.

AGENDA

08h30 : Accueil petit déjeuner

09h00 : Qui sommes-nous ?

09h15 : Introduction à l’ALM

09h45 : Présentation Improve Factory

10h15 : Démonstration de la plateforme

10h45 : Questions / Réponses

Adresse : Open Wide Technologies – 23-27 rue Daviel – 75013 – Paris
Contact : technologies@openwide.fr – 01.42.68.28.14

[Zenika] MongoDB Day Paris le 14 juin

2012-05-24T07:45:00Z

10gen - l'entreprise derrière MongoDB - organise le MongoDB Day Paris le 14 juin. MongoDB est une base de données orientée document et certainement un des produits NoSQL les plus populaires.

Le MongoDB Day Paris c'est : Une conférence avec 250 participants Plus de 20 sessions animées par des ingénieurs 10gen et des utilisateurs de MongoDB en production. Des sessions Ask the Expert, une nouveauté cette année, où vous pourrez passer du temps en tête à tête avec un ingénieur 10gen. Réservation indispensable ! Des ateliers de formation... Lire MongoDB Day Paris le 14 juin

[Adacore] GPS: display symbol names in memory view

2012-05-24T00:00:00Z

Memory view is extended to display symbol information.

[Zenika] Spring Batch and MongoDB: cursor-based item reader

2012-05-23T07:18:00Z

Spring Batch is a popular open source batch framework. It integrates with lots of RDBM technologies like JDBC, Hibernate or JPA, but doesn't have official support for NoSQL datastores yet. This post shows how to integrate Spring Batch and MongoDB to read large datasets from this document-oriented datastore.

What for? MongoDB is often used to store large sets of data like logs. When it comes to analyze such data, MongoDB provides simple aggregation operators or even MapReduce, but these technics are somewhat limited. There's even a new project to integrate MongoDB with Hadoop, but, hey, apart from web-scale applications, who wants to set up a Hadoop... Lire Spring Batch and MongoDB: cursor-based item reader

[Compatible One] CompatibleOne OSCi Workshop March 2012

2012-05-22T16:57:53Z

CompatibleOne OSCi Workshop

[Smile] Smile, partenaire Platinum du Liferay Symposium 2012

2012-05-22T08:39:27Z

Le second symposium de Liferay en France se tiendra le mercredi 23 mai 2012, à Paris aux Salons Du Pré Catelan – Lenôtre.

[CubicWeb] Thoughts on CubicWeb 4.0

2012-05-21T16:04:00Z

This is a fairly technical post talking about the structural changes I would like to see in CubicWeb's near future. Let's call that CubicWeb 4.0! It also drafts ideas on how to go from here to there. Draft, really. But that will eventually turn into a nice roadmap hopefully.

The great simplification

Some parts of cubicweb are sometimes too hairy for different reasons (some good, most bad). This participates in the difficulty to get started quickly. The goal of cubicweb 4.0 should be to make things simpler :

Fix some bad old design.
Stop reinventing the wheel and use widely used libraries in the Python Web World. This extends to benefitting from state of the art libraries to build nice and flexible UI such as Bootstrap, on top of the JQuery foundations (which could become as prominent as the Python standard library in CubicWeb, the development team should get ready for it).
If there is a best way to do something, just do it and refrain from providing configurability and options.

On the road to Bootstrap

First, a few simple things could be done to simplify the UI code:

drop xhtml support: always return text/html content type, stop bothering with this stillborn stuff and use html5
move away everything that should not be in the framework: calendar?, embedding, igeocodable, isioc, massmailing, owl?, rdf?, timeline, timetable?, treeview?, vcard, wdoc?, xbel, xmlrss?

Then we should probably move the default UI into some cubes (i.e. the content of cw.web.views and cw.web.data). Besides making the move to Bootstrap easier, this should also have the benefit of making clearer that this is the default way to build an (automatic) UI in CubicWeb, but one may use other, more usual, strategies (such as using a template language).

At a first glance, we should start with the following core cubes:

corelayout, the default interface layout and generic components. Modules to backport there: application (not an appobject yet), basetemplates, error, boxes, basecomponents, facets, ibreadcrumbs, navigation, undohistory.
coreviews, the default generic views and forms. Modules to backport there: actions, ajaxedit, baseviews, autoform, dotgraphview, editcontroller, editforms, editviews, forms, formrenderers, primary, json, pyviews, tableview, reledit, tabs.
corebackoffice, the concrete views for the default back-office that let you handle users, sources, debugging, etc. through the web. Modules to backport here: cwuser, debug, bookmark, cwproperties, cwsources, emailaddress, management, schema, startup, workflow.
coreservices, the various services, not directly related to display of something. Modules to backport here: ajaxcontroller, apacherewrite, authentication, basecontrollers, csvexport, idownloadable, magicsearch, sessions, sparql, sessions, staticcontrollers, urlpublishing, urlrewrite.

This is a first draft that will need some adjustements. Some of the listed modules should be split (e.g. actions, boxes,) and their content moved to different core cubes. Also some modules in cubicweb.web packages may be moved to the relevant cube.

Each cube should provide an interface so that one could replace it with another one. For instance, move from the default coreviews and corelayout cube to bootstrap based ones. This should allow a nice migration path from the current UI to a Bootstrap based UI. Bootstrap should probably be introduced bottom-up: start using it for tables, lists, etc. then go up until the layout defined in the main template. The Orbui experience should greatly help us by pointing at hot spots that will have to be tackled, as well as by providing a nice code base from which we should start.

Regarding current implementation, we should take care that Contextual components are a powerful way to build "pluggable" UI, but we should probably add an intermediate layer that would make more obvious / explicit:

what the available components are
what the available slots are
which component should go in which slot when possible

Also at some point, we should take care to separate view's logic from HTML generation: our experience with client works shows that a common need is to use the logic but produce a different HTML. Though we should wait for more use of Bootstrap and related HTML simplification to see if the CSS power doesn't somewhat fulfill that need.

On the road to proper tasks management

The current looping task / repo thread mecanism is used for various sort of things and has several problems:

tasks don't behave similarly in a multi-instances configuration (some should be executed in a single instance, some in a subset); the tasks system has been originally written in a single instance context; as of today this is (sometimes) handled using configuration options (that will have to be properly set in each instance configuration file);
tasks is a repository only api but we also need web-side tasks;
there is probably some abuse of the system that may lead to unnecessary resources usage.

Analyzing a sample http://www.logilab.org/ instance, below are the running looping task by categories. Tasks that have to run on each web instance:

clean_sessions, automatically closes unused repository sessions. Notice cw.etwist.server also records a twisted task to clean web sessions. Some changes are to come here following the coming session refactoring (that will become more and more necessary to move on several points listed here).
regular_preview_dir_cleanup (preview cube), cleanup files in the preview filesystem directory. Could be executed by a (some of the) web instance(s) provided that the preview directory is shared.

Tasks that should run on a single instance:

update_feeds, update copy based sources (e.g. datafeed, ldapfeed). Controlled by 'synchronize' source configuration (persistent source attribute that may be overridden by instance using CWSourceHostConfig entities)
expire_dataimports, delete CWDataImport entities older than an amount of time specified in the 'logs-lifetime' configuration option. Not controlled yet.
cleanup_auth_cookies (rememberme cube), delete CWAuthCookie entities whose life-time is exhausted. Not controlled yet.
cleaning_revocation_key (forgotpwd cube), delete Fpasswd entities with past revocation_date. Not controlled yet.
cleanup_plans (narval cube), delete Plan entities instance older than an amount of time specified in the configuration. If 'plan-cleanup-delay' is set to an empty value, the task isn't started.
refresh_local_repo_caches (vcsfile cube), pull or clone vcs repositories cache if the Repository entity ask to import_revision_content (hence web instance should have up to date cache to display files content) or if 'repository-import' configuration option is set to 'yes'; import vcs repository content as entities if 'repository-import' configuration option and it is coming from the system source.

Some deeper thinking is needed here so we can improve things. That includes thinking about:

the inter-instances messages bus based on zmq and introduced in 3.15,
the Celery project (http://celeryproject.org/), an asynchronous task queue, widely used and written in Python,

Remember the more cw independent the tasks are, the better it is. Though we still want an 'all-integrated' approach, e.g. not relying on external configuration of Unix specific tools such as CRON. Also we should see if a hard-dependency on Celery or a similar tool could be avoided, and if not if it should be considered as a problem (for devops).

On the road to an easier configuration

First, we should drop the different behaviour according to presence of a '.hg' in cubicweb's directory. It currently changes the location where cubicweb external resources (js, css, images, gettext catalogs) are searched for. Speaking of implementation:

shared_dir returns the cubicweb.web package path instead of the path to the shared cube,
i18n_lib_dir returns the cubicweb/i18n directory path instead of the path to the shared/i18n cube,
migration_scripts_dir returns the cubicweb/misc/migration directory path instead of share/cubicweb/migration.

Moving web related objects as proposed in the Bootstrap section would resolve the problem for the content web/data and most of i18n (though some messages will remain and additional efforts will be needed here). By going further this way, we may also clean up some schema code by moving cubicweb/schemas and cubicweb/misc/migration to a cube (though only a small benefit is to be expected here).

We should also have fewer environment variables... Let's see what we have today:

CW_INSTANCES_DIR, where to look for instances configuration
CW_INSTANCES_DATA_DIR, where to look for instances persistent data files
CW_RUNTIME_DIR, where to look for instances run-time data files
CW_MODE, set to 'system' or 'user' will predefine above environment variables differently
CW_CUBES_PATH, additional directories where to look for cubes
CW_CUBES_DIR, location of the system 'cubes' directory
CW_INSTALL_PREFIX, installation prefix, from which we can compute path to 'etc', 'var', 'share', etc.

I would propose the following changes:

CW_INSTANCES_DIR is turned into CW_INSTANCES_PATH, and defaults to ~/etc/cubicweb.d if it exists and /etc/cubicweb.d (on Unix platforms) otherwise;
CW_INSTANCES_DATA_DIR and CW_RUNTIME_DIR are replaced by configuration file options, with smart values generated at instance creation time;
the above change should make CW_MODE useless;
CW_CUBES_DIR is to be dropped, CW_CUBES_PATH should be enough;
regarding CW_INSTALL_PREFIX, I'm lacking experience with non-hg-or-debian installations and don't know if this can be avoided or not.

Last but not least (for the moment), the 'web' / 'repo' / 'all-in-one' configurations, and the fact that the associated configuration file changes stinks. Ideas to stop doing this:

one configuration file per instance, with all options provided by installed parts of the framework used by the application.
activate 'services' (or not): web server, repository, zmq server, pyro server. Default services to be started are stored in the configuration file.

There is probably more that can be done here (less configuration options?), but that would already be a great step forward.

On the road to...

The following projects should be investigated to see if we could benefit from them:

Paste (http://pythonpaste.org/, Configuration and all)
Beaker (http://beaker.readthedocs.org/en/latest/index.html, More on Session / cache handling than what will be found in Werkzeug?)
Pyramid's debug toolbar (http://docs.pylonsproject.org/projects/pyramid_debugtoolbar/en/latest/). See also http://firelogger.binaryage.com/#python. Notice Werkzeug come with an integrated js console as well.
zc.buildout (Deployment)

Discussion

Remember the following goals: migration of legacy code should go smoothly. In a perfect world every application should be able to run with CubicWeb 4.0 until the backwards compatibility code is removed (and CubicWeb 4.0 will probably be released as 4.0 at that time).

Please provide feedbacks:

do you think choices proposed above are good/bad choices? Why?
do you know some additional libraries that should be investigated?
do you have other changes in mind that could/should be done in cw 4.0?