Nuxeo Developers Blog

luma LDAP client : PyQT based UI

Just found out that the "good old" gq is not maintained anymore. (see : http://biot.com/gq/)

Had to look for another one and found luma (http://luma.sf.net) which is a PyQT interface based application :)

Really nice !

Here's couple of snapshots  there : http://luma.sourceforge.net/screenshots.html

I really would like to see such kind of app integrated with KDE though :)

(Post originally written by Julien Anguenot on the old Nuxeo blogs.)

Promising Zope-3.2 and Twisted integration

I discussed with Stephan yesterday on IRC about the Zope3 and Twisted integration and just wanted to drop a blog related to this.

Stephan did a great work with Michael Kerrin integrating Zope3 with Twisted. (A branch is already waiting for Zope-3.2 there. and they've been in touch with the Twisted guys all along this work. This is really promising !

I found this integration interesting for two reasons. The first reason, it's something that lots of Zope hackers are waiting for because Twisted is a really powerful framework that was unfornately hard to use with Zope until now (which was of course preventing Zope devels to dig into Twisted more deeply) and the second reason is that we can hope to see the developers from both projects trying to work together and use both frameworks on both sides.

The thing now is to convince the Twisted folks to use Zope3 :) It seems they are developing their own stuffs such as newo or even their own persistency mechanims (persisted component) and probably tons of other things I'm not aware of...

For someone involved in Zope2 for a while this it typically the kind of Python symptom you'll often find that consists of always reinventing the wheel since it's often easier to recode your own stuffs than integrating someone's else code and communicate with the folks maintaning it. We agreed it's bad and a waste of ressources after Zope2 and all the CMS projects around Zope2...

I really hope both Twisted and Zope hackers will check and use more each other framework, share components and exchange patches. It will be so great merging somehow hackers from both communites !

Twisted folks : check Zope3 !  (It will be using Twisted right -:))

(Post originally written by Julien Anguenot on the old Nuxeo blogs.)

Zope-3.1 bug day on Friday 29th for the first 3.1 RC

For those who didn't get to read the Zope3-dev mailing list, a bug day is planned for this friday (29th) to fix the remaining bugs on the trunk for the 3.1 release.

See Stephan mail there :
http://mail.zope.org/pipermail/zope3-dev/2005-July/015014.html

We can expect the first RC of Zope-3.1 after this. Youpie !

Personally, really excited about this because it means the feature freeze on the trunk will go away, with a dedicated 3.1 branch, and then the 3.2 developments will start which will include for instance, for the stuffs  I'm following myself : 

• lxml dependency
• xpdlcore
• Twisted integration ! :) (This wil rock !)
• Jean-Marc's cpsskins  ( the rumor says ;) )
  

and of course much more in the pipe after this :)

(Post originally written by Julien Anguenot on the old Nuxeo blogs.)

Is ZEA trying to steal Zope's logo in Europe and slow down the Zope Foundation?

Origin of the trademark issue

At Europython, I was told that the Zope Europe Association (ZEA) registered the trademark (they exactly registered "Circle-Z + the zope word", the Zope logo actually) about one year and an half ago without letting Zope Corporation (ZC) know. This surprised and shocked me a bit but worse was coming.

Six months before ZEA registration, Zope Corp registered the trademark Zope (only the word) in Europe (6 countries at least) using the Madrid Protocol, at the World Intellectual Property Organisation (WIPO). ZEA's registration is thus invalid (or illegal), in at least those 6 countries. Rob Page (CEO of ZC) told me that he will ask ZEA to transfer the mark to ZC (avoiding the delay and cost of a cancellation procedure) and that ZC really wants the mark clean and owned by them as a pre-requisite for creating the Zope Foundation. I was thinking that ZEA would accept the transfer without any problem (since they registered it only to protect it).

One day, drinking my coffee, I read a mail from Rob Page (CEO of ZC) saying that ZEA doesn't want to transfer the copyright back to Zope Corp. (even if Zope Corp. indemnify them with the amount it cost to buy the mark in Europe). I couldn't believe this! ZEA was also agreeing to transfer the mark to the Zope Foundation (not Zope Corporation) in exchange for a certain amount of money (20 K euros which is apparently more than the real cost of such a registration).

The big problem is that Zope Corp is willing to license irrevocably Zope trademark to the Zope Foundation. Such a license is not possible with a trademark dispute running on and the Zope Foundation will consequently be delayed (since it could create some legal problem for the Foundation or for Zope Corp).

How can we understand ZEA transfer refusal? What is the point of view and the position of Nuxeo (that is the biggest Zope dedicated company in the world, with Zope Corp. — Yes I like writing that, if you are wondering :-)? Here it comes...

Point of view

ZEA is illegitimately owning the mark (and an invalid mark :-). ZEA is not a charity. ZEA is an association of companies that aims at selling projects and that is bidding in Europe on some deals, against other companies. No problem with that, we are in a free market. But I would like to stop reading things like "ZEA represents the european Zope community". It does not.

ZEA represents only its members' interest not ones of the whole Zope Community in Europe. Again, no problem with that, it's totally normal, but please don't claim anything else.

My concern on this topic is the claim of protecting Zope Community interests in Europe against the evil american company... Well, at Nuxeo, a pure european company, we really prefer to see this mark in the hand of Zope Corp. And we prefer that for two main reasons :

• First Zope Corp. was the key player that produced Zope code, invented the name, designed the logo, put the code OSS and spend some money to market it. Why would someone steal this property?  Why would someone bite the hand that feeds him? Especially when this one is eating each day. So unfair!
• Then, Nuxeo is not ZEA's member (it's our choice, even if I can't remember to have received any invitation) so ZEA doesn't represent our interest. I don't see any reason to prefer to have the mark owned by ZEA than ZC from this point of view. But since ZEA seems to be unfair, I can feel some danger letting them keep the logo of the technology that supports our core business. Disclaimer: we don't see ZEA as a competitor and even if it would be the case, competition is healthy... when it's fair!

Impact on the Zope Foundation and the whole Zope Community

After some discussions, Zope Corporation made a clear sign to the community: they are in the process of creating a Zope Foundation to hold the copyright of Zope (2 and 3) and to manage this Open Source project (and related projects if ZF wants to). That is a big chance for the whole Zope Community to solidify Zope's image with an independent entity managing it: more members will be involved, more solid and credible the technology will be. I was thinking "Eventually, this is the final boost Zope needs to explode and take a big part of the application servers market", working at this project and waiting for the Foundation official launch... I won't explain here all the benefits of such a foundation and how it will ease and boost Zope's business and use, this post is about ZEA's big mistake. But clearly it is really damageable to slow down the launch of our awaited Foundation.

Is ZEA willing to slow the foundation launch?

The direct impact of ZEA's mess is slowing down the Zope Foundation launch (really expected and applauded by a large majority of the Zope Community when announced (IRC, Zope list, Europython, etc.)).

With Zope Foundation owning Zope code and managing the project, the whole community is assured that Zope is secured even if Zope Corp is bought by VeryVeryEvilBadCorp! That was expected by so many people (including many ZEA members and ZEA board members) for more than 2 years...

So, why would Zope community active members and democracy / cooperation herald be willing to stop or slow the Zope Foundation? I really don't know, even if they would fear to lose some illegitimate power in favor of a legitimate and independent entity...

Note: if I was Zope Corp. I wouldn't have proposed to indemnify: ZEA did something illegal and they have to repair that mistake (I will presume that they did a mistake, not an intentional law infringement when registering). And really don't have to pay for other's mistake.

About trademarks' "fair usage" and irrational fears

These days, I can read many mails about how Zope Corp can be bad, owning the whole copyright (but give me one reason to not apply those fear to ZEA instead of Zope Corp?). Some seems to think that Zope Corp. would have the power to prevent people to use, write and pronounce the word Zope.
The reality is a little smoother and fair :-)

There is something called "fair use" that is commonly accepted. It specifies that an owner has to authorize others to use his trademark if there is no other way to say something and/or if there is no confusion about the source.

For example, you use "MySoWonderfulCompany provides worldwide Zope wonderful experts to develop very large projects" in all you marketing material. Well, nobody can prevent you to use this sentence if you're really doing Zope stuff. But, if you say "MySoWonderfulCompany provides Zope services" and you basically are providing Java or C# stuff, Zope Corp will sue you, take your home and make your wife leave! :-)

In short, there is no way for Zope Corp to prevent anyone to use Zope, if those people respect the source (do not say that you are Zope inventor — actually, if you say that, you might fear a lot more Jim's supernatural power than ZC ;-) and if they really are using / providing / coding on / selling Zope. Don't forget that the Foundation will own the code and manage the project, if we can create it!

And the more important is that nobody has interest in preventing anybody that is doing Zope stuff from using the Zope trademark: we all have interest in make Zope stronger, more famous, more used and more known (especially ZC and ZC acquirer if there is one some day, I think).

Call to ZEA's members

To conclude this, I want to make a call to all ZEA members and ask them to stop this trademark dispute that is:

• unfair for Zope Corp. (what would you be selling, right now, if ZC would never have released Zope as OSS?) and ZEA non-members (do we really need to act as competitor? I would prefer to see all of us — members and non-members of ZEA — acting as partners willing to develop and expand Zope market).
• damageable for Zope image: what does this mean for your current and potential customers? What will people think of our community seeing this kind of childish dispute? Well, maybe we could all act as professional and stop shouting at / hitting each other and concentrate all our effort to build a strong community, a rock-solid platform and a large usage... We have talked a lot about the Zope 10x project for years, I see this issue as reverse marketing ROI :-)
• useless and non-productive for all of us: count the time we are spending on this issue... Is there nothing better to do?
• slowing Zope Fondation launch: is it really what you are expecting? If the answer is yes, I will do all I can to take the mark back from ZEA because I will begin to worry about ZEA's real intention and goal...

All of you, ZEA members, please make ZEA give back this mark to its legitimate owner and stop this silly dispute to eventually allow the launch of the Zope Foundation! I'm sure the whole Zope community would really appreciate and thank you all in advance!

Now, let's focus on kicking Documentum ass... :-)

(Post originally written by Eric Barroca on the old Nuxeo blogs.)

[OOo]Contributing is not only coding ...

Well, in fact, coding is the most important to me :)

But, today DicOOo is now translated into norvegian, with its 2 sublanguages no and nn. FontOOo is on the rails and will be released soon ... Thanks to the norvegian team, 24 hours after exchanging the first mails, the job is done ...

OOo is a multiplateform program, but the most important to me, OOo is a multilingual and multicultural project. That's why native-lang teams are so important. They are dynamic ...

So yes, coding is important but OOo Addon Coders, prepare your programs to be easily translated. They will then be useful to a majority of users ...

This point will be addressed by the scripting project ... A usefull addon means, yes, a good program, but also good testing, translating, support ...

More than Addons, OOo also share these needs ... so many ways to contribute

(Post originally written by Laurent Godard on the old Nuxeo blogs.)

RMLL2005 : My slides from the Python track are available

Finally, I took some time to publish my slides from the libre software meeting that occured 2 weeks ago in Dijon. These slides are in French and you may download them in pdf or OpenDocument formats.

The topics were Python and XML and Introduction to Zope3

You can grab them there from the AFPY website.

Congrats to Tarek for the organization of the Python track !

Cheers,

(Post originally written by Julien Anguenot on the old Nuxeo blogs.)

[OOo] A new CCR elected :)

Last week was the time for the election of the new CCR (Community Contributor Representative) of the OpenOffice.org project. The results are now known and I'm very honored being chosen among great names of the community to be the representative of all OOo contributor.
Here is the official announcement

So thanks to all who voted (not only for me) showing that involvement is growing inside OOo project. I'm really proud to be this voice for the coming 6 months.

Now, it's time to work and prepare great things to attract more and more contributors.
Yes, core developpers are needed but one other way is to attract all the scripters we can !
OOo 2.0 will bring a lot of possibilities (with Basic,java, javascript but also Python internal scripting) and it is now time to build and animate a strong Scripting project. The first proposals i'll made will be based on my IRC conf in April. Once some tools built and a real team involved, we will be able to explore other possibilities such as models, galleries ... on-line installation.

This is only a part of the job. I'm totally open to all questions/suggestion i can relay to the community council i'm now a part of.

Stay tuned and come to help, you're welcomed ...

(Post originally written by Laurent Godard on the old Nuxeo blogs.)

zasyncdispatcher, a small load balancer for background processes using zasync

Thanks to zasync, I can send some processes to the baground in zope (see past posts in this blog)

We have an intranet where we want to distribute background processes to several machines, so we want to use several zasync clients to maximize the number of simultaneous bakground processes.

Based on the recipe Gary Poster gave me, I have created a tiny Z2 product (about 10 lines of code) that instanciate a folderish object in the ZODB and let the admin create asynchronous call manager objects in it.
Each asynchronous call manager object is linked to a zasync client by changing a few params in the conf file.

The folder object (=the dispatcher) publishes a few APIs (putCall, putSessionCall)

My code calls it and let the dispatcher choose wich asynchronous call manager is the less busy and forward the call to it.

That let the administrator freely add or remove zasync clients, it's  pretty smooth :)

Thanks Gary !

the code is here if you want to use it:

http://svn.nuxeo.org/trac/pub/browser/zasyncdispatcher/

(Post originally written by Tarek Ziadé on the old Nuxeo blogs.)

Advanced security machinery in Zope2

In the new calendar project we have the need for changing the access to an object depending on the the attributes of the object. For example, you should not be able to view an event unless one of these conditions are fulfilled:

1. You are invited to the event
2. You have the right to view the calendar of somebody who is invited and the event is a public event
   
3. You are the manager of somebody invited to the event (even if the event is set as private).

Also, you can only edit the event of you are the event organizer, or the event organizers manager.

There are two basic paths to walk down here. The simplest, and usually the best, is to simply recalcuate the security when you change the event. I chose not to go that path this time, mainly because there are no good hooks to use in pure Zope2. In CPS we have an event system that would work well for this, and the same is true for Zope3, but since the calendar needs to work in pure Zope2 it's not possible. Creating hooks on the events themselves would be possiblem but we would then also need hooks on the calendars to be able to recalculate the security when the security settinsg change on a calendar.

Also, there is a risk that recalculating the security takes a long time of you have many events in the calendar.

So instead, I opted to create the security settings dynamically, when accessed. This requires using a couple of advanced Zope 2 security mechanisms that I think is worth a blog.

Acquisition wrapping

The first "trick" is to make it possible to have security settings on the attendee object. Since the attendee objects are non-persistent objects (they may originate from an external user source, for example) we can't just store the permission settings on the objects as is normal in Zope2. Also, even if we did store the settings in the calendar tool somehow, having a good user interface for this is not trivial.

Therefore, we decided to use the attendees main calendar as a "proxy" for the attendee settings. You give people a role on the calendar, and they will have the same role on the attendee. The result is mainly that you can check access settings directly on the attendee, instead of having to look up the main calendar for the attendee and check there. It greatly simplifies use of the calendar for developers.

The "trick" is simple, we need to make the attendee appear as if it is a subobject of it's own main calendar:

  def getAttendee(self, attendee_id):

    attendee = Attendee(attendee_id, attendee_id, 'INDIVIDUAL')

    homecal = self.getMainCalendarForAttendeeId(attendee_id)

    if homecal is None:

      return attendee.__of__(self)

    # This is to acquire the security settings from the calendar:

    return attendee.__of__(homecal)

It is the __of__ method that wraps the attendee so it looks like a subobject. If the attendee seems to have no homecalendar, it gets the security settings of the calendar tool instead.

We also do the same trickery for events, but for another reason. We in the case of events want to to actually look like, through the user interfaces, as the events are subobject of the calendar. This allows us to have proper crumbtrails and the like. Attendee objects however, have no visible user interface, so for attendeesd this is done only to simplify the security checking on attendees.

An __ac_local_roles__ method

Usually __ac_local_roles__ is a dictionary of user ids and roles. But Zope 2 allows you to make it a method that returns this dictionary instead. So for an event, I can return a dictionary containing all the people and resources attending an event, and giving them the appropriate "EventAttendee" role.

In fact, to return a complete dictionary, I also need to go through all the attendees to see which users have the AttendeeManager role on their calendars, and give them the EventAttendee role to those users as well (see the mentioning above of being somebodys manager). But this can take a very long time if you have many attendees, so I have simplified it. I'll only check the current user, and only the current calendar. That is, even if you have the right to view an event through Martijns calendar, you may not have the right to view the same event through Erics calendar. You also will not be able to check what the permissions another user has. Other users will always look like they have no permissions at all on events. This simplifies the code a lot and speeds up the security handling.

  def __ac_local_roles__(self):

    # Find the current attendee id:

    attendee_src = self.portal_calendar.attendee_source

    current_attendee = attendee_src.getCurrentUserAttendee()

    current_id = current_attendee.getAttendeeId()

    attendees = [current_id]



    # Check if the current user is an attendee manager for this calendar

    current_user = getSecurityManager().getUser()

    calendar = self.getCalendar()

    roles = current_user.getRolesInContext(calendar)

    if 'AttendeeManager' in roles:

      # Current user is attendee manager for this calendars user, so

      # We'll add this calendars user to the list of current attendees

      attendees.append(calendar.getAttendees()[0].getAttendeeId())



    # Check if the current organizer is one of the relevant users, in that

    # case we should get the organizer role as well as local roles:

    if self.getOrganizerId() in attendees:

      roles.append('EventOrganizer')

   

    # Check through the attendees to see if they are participating:

    event_attendees = self.getAttendeeIds()

    for id in attendees:

      if id in event_attendees and 'EventParticipant' not in roles:

        roles.append('EventParticipant')

    return {current_user.getId(): list(roles)}

Dynamic permission proxying

This last technique is probably the least obvious, as it is really a combination of two: Permission proxying and overriding __getattr__.

In Zope2, the roles that have a permission on a particular object is stored in an attribute called "_[name_of_permission]_Permission". For example _View_event_Permission in the case of the permission named "View event". This should be a tuple of roles. In the case of events, we really want the View event to have different sets of roles depending on if the event is public or private. We can make that happen by overriding the events __getattr__-
However returning dictionaries of roles in this case means that the mapping between roles and permissions is fixed, which means that the normal security settings in Zope no longer has any impact on the permission to role mapping for this permission. Breaking standard functionality like that is not a good idea, but luckily there is a method to get around this as well. The permission attribute can be a string instead of a tuple of lists. If it is a string, it is assumed to be the name of another permission, and that permission is used instead. This way we can have three permissions; one for viewing public events, one for viewing private events, and a third "proxy permission" for viewing events that returns the correct permission to use for this event:

  def __getattr__(self, name, default=_marker):

    # View event is a "proxy permission". Nobody actually needs to

    # have that permission, instead, the name of the permission to

    # be used is returned.

    if name == '_View_event_Permission':

      if self.__dict__['access'] == 'PUBLIC':

        return '_View_public_event_Permission'

      else:

        return '_View_private_event_Permission'

    if default is _marker:

      return getattr(self.__dict__, name)

    return getattr(self.__dict__, name, default)

As you see, every time the permission "View event" is accessed, the security machinery is told to look at "View private event" or "View public event", depending on if the event is public or private.

(Post originally written by Lennart Regebro on the old Nuxeo blogs.)

[OOo]Version 1.1.5 : les test QA commencent

La version 1.1.5 d'OpenOffice.org est disponible depuis peu en  RC.
Sa raison d'être est principalement d'implementer le format OpenDocument, format de fichier standardisé par le consortium OASIS et qui sera le format par défaut de la version 2.0.
La version 2.0 gerera bien sur l'ancien format sx* (sxw, sxc, sxi, ...). La réciproque est desormais vrai, la version 1.1.5 gerera les format od* (odt, ods,odp ...)
Ainsi, le passage de la branche 1.1.x à la branche 2.x devrait s'effectuer sans problème dans le temps

La communauté francophone attaque pour sa part les test QA (ce qu'elle fait pour chaque version, voire pour la 2.0, certaines Beta). Nous devrions avoir terminé les smoketests aux alentours du 24/07. Tous les renseignements sur le sous-projet QA-fr

(Post originally written by Laurent Godard on the old Nuxeo blogs.)