betabug: ftp is meant for the dumpster of digital technology anyway
hpeter: webdav is already running ... client wants ftp
hpeter: that's why i tried ftp-proxy
betabug: hpeter: state security concerns, ftp is insecure, webdav can be run over https
betabug: only terrorists use ftp
betabug: or worse: if we still use ftp, the terrorists have won!

[Fill in Usual Disclaimers] + You don't want to do this on a shared instance since your're patching the ftp-server of your instance!

I found the suspected code in the __init__ method of zope_ftp_channel in ZServer/FTPServer.py.

You only have to change self.path='/' into self.path='/[whatevernameyouwant]' and your entering path for ftp will change to that url. You can still do a CWD and enter any other directory you have the permission to.

from ZServer.medusa.ftp_server import ftp_channel
from ZServer import requestCloseOnExec
from ZServer.FTPServer import zope_ftp_channel 

def patched_ftp__init__ (self, server, conn, addr, module):
    ftp_channel.__init__(self,server,conn,addr)
    requestCloseOnExec(conn)
    self.module=module
    self.userid=''
    self.password=''
    self.path='/plone'
    self.cookies={}

print "patched ftp root for login redirection"

zope_ftp_channel.__init__ = patched_ftp__init__

I'm certain there is a better, nicer,... way of doing this, that's the nature of a patch ;-)

Picture by Egan Snow under cc by-sa http://www.flickr.com/photos/egansnow/268912449/

Yesterday I meet Robert to finish work on cornerstone.soup after our cologne alliance partner Sven found an odd bug. We simplified the soup recipe, but now its really yummy. Version 1.0 is released.

cornerstone.soup is a genric storage for mass-data in an isolated container. Light-weight records are stored in an IOBTree. A Zope-Tool-Kit catalog in used to index values of interest. cornerstone.soup is no out-of-the-box package. Its addressed to developers needing to solve the problem of storing tiny entities of mass-data, where heavy weight archetypes or dexterity are too much effort and are to slow. I.e if you need a container for non-CMSish content, like votes, data from a poll, orders in a webshop, measuring data, or alike.

Isolated means, for each soup we store all in one persistent local utility. Stored are generic „Records“ which are persistent items with attributes passed in at construction time as keyword arguments. Also the catalog with its indexes is part of the local utility. Items are accessed by query.

We tested the soup with Zope 2.10 and Zope 2.12. It works in a plain Zope. We are using it at the moment in a Plone 3.3

For more information read the documentation at pypi: cornerstone.soup.

Now after two successful days of the sprint  we have a good outcome.

Michael Launay and Vincent Fretin from Ecreall  (Lille/ France) arrived Wednesday evening after a 1000km car-ride and joined Robert and Jens at BlueDynamics Office in Innsbruck Thursday morning. After synchronizing our minds showing what was done so far we started pair-programming. We expected Gogo from Vienna to join us in the evening, but he got ill and was not able to get on his flight. But fortunately he started to help out remotely.

Michael + Jens worked on the UML internal model. The import of XMI to UML, and the internal model (class-diagram) representaion was already finished by Jens and Robert in the last 3 weeks. Now the real difficult work had to be done: Get useful information out of the model. We wrote some convinience classes following roughly the adpater pattern (but not using ZCA here). Its all tested and documented by doctests - I'd say we have a very good coverage. Most of the time was needed to find the edge-cases in modelling.

Vincent + Robert paired to work on the transformation and generation of Python-code. The connection of the transformations as a chain works now. The generation for filesystem-structures is almost done. Python generation is work in progress and task for today. Gogo helped here by taking specific tasks. All code is tested and documented with doctests as well.

Today we plan to finish the UML convinience API and get the core work for Python-code-representation in a tree done. If this is done we can start writing our first real code generation chain: And what will it be? No, not Plone-code: We will generate AGX-generators! This means: python eggs, packages, modules, methods, classes and decorators.

for the agx-sprint team

-- Jensens

After the great Plone Conference in Budapest and its sprint we did a huge step forward to a working AGX transformation chain. Last friday november the 6th we sprinted internally on the AGX engine and now have a working XMI to UML transformation. Some tiny bits are missing, but the overall transformation works. The UML to Python transformation is about 40% finished either.

We invite everybody interested in writing handlers for code generation to a three day development-sprint in Innsbruck.

Goals are:

1. Getting more people into AGX and showing them the easiness of writing AGX transforms.
2. Finish the Python-Code-Generation
3. Invent a domain-specifc UML language (profile) for Dexterity.
4. Generate Dexterity types for Plone 4.
   

It will be held at the office of Klein & Partner KEG. We start at November 26th at 9:00 am. Our office is available the whole 24h of 3 days until Nov 28th. We help booking accomodiation and recommend Hotel Zillertal  (where we probably get 10% reduction - waiting for conformation). Snacks, lunch-buffet and drinks are available. For those still needing x-mas presents I can recommend the famous Christkindl-Market.

Contact: jens@bluedynamics.com

BlueDynamics Alliance is at Plone Conference in Budapest! Peter Holzer, Robert Niederreiter and me, Jens Klein. Also Johannes Raggam, our intern from last year is here.

Its good to meet all the people from Plone Community. Amazing how many new people are here!

We are listing to some interesting talks and if theres no we started to sprint on AGX, the framework for tree-transformations which is the base of the new (Code-) Generator.

I prepared a lighting talk on cornerstone.soup, our lightweight isolated conatainer for queryable records - based on ZTKand made for Plone.

Robert prepared a lightning talk about AGX. Johannes will show the outcome of his thesis, a "activity model runtime engine for python" - which uses AGX and the underlying zodict-Node.