porcupine blog

Features of the forthcoming Porcupine release

Sun, 18 Apr 2010 00:00:00 +0300

The forthcoming Porcupine release includes a whole new bunch of exciting features and improvements. This is a list of the most significant:

1. Python 3 compatibility. The new version will require Python 2.6 or later but it will also be Python 3 compatible. Since the bsddb module is deprecated, an extra dependency to pybsddb is added. Porcupine will continue to support both modules with pybsddb having priority over its predecessor.

2. High availability and horizontal scalability by using single master-multiple slave database replication to n Porcupine nodes. The web connector acts as a software load balancer for the back-end nodes using round-robin.

3. New redesigned database. The main Porcupine DB is now a b-tree instead of hash. All children of a container are now stored adjacently. Locality of reference plays an important part in database performance.

4. Support for JSON-RPC 2. JSON is more compact and readable than XML. All remote methods handle this transparently based on the content type of the request.

5. Enhanced OQL query optimizer.

6. Elastic schema that allows easy schema updates without requiring database updates. The database is physically inconsistent but the API enforces consistency. Each object becomes consistent the next time it is updated. This requires code updates since the __props__ class attribute of the content classes has significantly changed.

7. The upcoming release will also include a template engine (py-normal-template) that enforces MVC.

8. Using swfupload instead of the applet for uploading files. The applet blocks JavaScript execution while the user selects files. This was potentially interpreted as an unresponsive script by most browsers.

9. QuiX now supports right-to-left layouts for the Arabic speaking countries. The whole UI mirroring is handled transparently and this is done just by adding an extra attribute to the desktop widget.

10. Although all dates are stored in UTC, they were transferred using the server's time zone. Now this is no longer true. Dates are transferred in UTC format and converted to local dates on the client based on its time zone.

If you want to test-drive these new features check out the Porcupine development version found at http://github.com/tkouts.

Introducing Normal Template for Python

Sun, 14 Feb 2010 00:00:00 +0200

Normal Template is a template engine originally developed by my friend George Moschovitis in JavaScript. What I really like about Normal Template is its simplicity, compactness and its clean JSON-ish approach.

Therefore, I decided to write a Python port and use it as an alternative out-of-the-box template engine for the upcoming release of Porcupine. Normal templates are safe, applicable to any non XML/HTML contexts and portable to any programming language.

Sample usage:

template.html

<html>
<h1>Hello {=name}</h1>

{:select profile}
<p>
{=age}<br/>
{=gender}<br/>
</p>
{/:select}

<p>Your age is {=profile/age}</p>

<ul>
{:reduce articles}
<li>{=title} - {=count}</li>
{:else}
<li>No articles found</li>
{/:reduce}
</ul>

{:if admin}
You have admin rights
{:else}
You don't have admin rights
{/:if}
</html>

template.py

from normaltemplate import *

template_file = open('template.html')
src = template_file.read().decode('utf-8')
template_file.close()

# compile template into a Python function
template = compile(src)

data = { // the data dictionary in JSON format
'name' : 'George',
'profile' : {
'age' : 34,
'gender' : 'M'
},
'articles' : [
{ 'title' : 'Hello world', 'count' : 34 },
{ 'title' : 'Another article', 'count' : 23 },
{ 'title' : 'The final', 'count' : 7 }
],
'admin': True
}

# calling the template with the data dictionary
# returns the rendered output
print(template(data))

The code for py-normal-template is available on github at http://github.com/tkouts/py-normal-template. The original JavaScript implementation is available at http://github.com/gmosx/normal-template.

Stress testing Porcupine v0.6

Sun, 15 Nov 2009 00:00:00 +0200

Before releasing Porcupine v0.6 I have conducted a series of stress tests using Pylot. The aim of one of these stress tests was to benchmark Porcupine under extreme race conditions.

For this reason I created a test scenario with only two requests. The first request authenticates the "admin" user against the Porcupine database whereas the second request calls a remote web method that creates a common container object (folder) inside the root container object.
The test scenario is the following:

<testcases>
   
   <case>
      <url>http://192.168.233.115/porcupine.py/</url>
      <method>POST</method>
      <body><![CDATA[<?xml version="1.0"?>
         <methodCall>
            <methodName>login</methodName>
            <params>
               <param><value><string>admin</string></value></param>
               <param><value><string>admin</string></value></param>
            </params>
         </methodCall>
       ]]></body>
      <add_header>User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.8) Gecko/2009032609 Firefox/3.0.8</add_header>
      <add_header>Content-type: text/xml</add_header>
   </case>
   
   <case>
      <url>http://192.168.233.115/porcupine.py/</url>
      <method>POST</method>
      <body><![CDATA[<?xml version="1.0"?>
         <methodCall>
            <methodName>create_object</methodName>
            <params></params>
         </methodCall>
      ]]></body>
      <add_header>User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.8) Gecko/2009032609 Firefox/3.0.8</add_header>
      <add_header>Content-type: text/xml</add_header>
   </case>
</testcases>

The "create_object" web method is as simple as:

from porcupine.utils import misc
from org.innoscript.desktop.schema.common import Folder

@webmethods.remotemethod(of_type=RootFolder)
@db.transactional(auto_commit=True)
def create_object(self):
   f = Folder()
   f.displayName.value = misc.generate_oid()
   f.append_to('')
   return True

The stress test's duration was 10mins. It initiates 100 agents applying requests every 80ms with a warm-up time of 100secs. The command line is:

$ python run.py -a 100 -d 1200 -i 80 -r 100 -x porcupine_txn_test.xml -o results -n "Porcupine 0.6 Performance Results"

Due to the fact that that the root folder in this scenario is considered a highly demanded resource since all objects created are created inside this container the maximum number of concurrent transaction is lowered to 8 (max_tx setting).
The test's highlights are:
- Porcupine was able to serve more than 160K database requests in 10mins
- Half of the above requests were transactional which means more than 80K full ACID transactions where committed successfully (more than 65 transactions per second).
- Only 17 transactional requests could not be completed (exceeded maximum retries)
- The response time of 90% of the requests was less than 1sec.

The machine used for the test was a virtual ESX server with dual core processor and Ubuntu installed.

The detailed results can be found here.

FileTrack v0.1 is released!

Tue, 08 Sep 2009 00:00:00 +0300

The latest release of FileTrack, a Web enabled communication log that helps you to monitor all of your inbound and outbound documents, is now available for download. This is mainly a compatibility release being fully compliant with the API changes introduced in the latest Porcupine release (v0.6).

Download the application's package and then follow the installation instructions to install it.

For those still using an older Porcupine release, you can now upgrade to the Porcupine 0.6 and then also upgrade to the latest version of FileTrack using the standard installation procedure for ppf files, as described in the previous link.

For any problems you may encounter during the installation procedure, add your comment in this post for getting help.

Porcupine v0.6 is released

Sat, 18 Jul 2009 00:00:00 +0300

At last the new version of Porcupine is released. During the past months, I have put a lot of effort for making this release finally available. It includes a new whole bunch of new features and improvements, mainly aimed towards scalability.

The server now supports multiple processes by using the "multiprocessing" module introduced in Python 2.6. Unfortunately, due to a multiprocessing issue - which I hope will be resolved in later Python releases - the win32 executable doesn't support this new feature yet. Moreover, the new win32 setup executable comes with Microsoft's C++ 2008 redistributable libraries in order for the server to install correctly.
The Porcupine database now supports indexes declared at a server-wide scope inside the Porcupine configuration file (porcupine.conf). Currently, the indexes are used for common database usage patterns such as getting the children of a container, but not yet fully leveraged by OQL. For the time being, simple queries like

select something from 'container_id' where indexed_attribute=value

will leverage the index structure.
The Etag HTTP header is now fully supported for static files. For dynamic requests a new pre-processing filter is included that allows conditional Etags, meaning that an Etag header will be generated only if a predefined condition is true.
The Porcupine API is partially aligned with Python's PEP 8. The majority of the API calls are no longer camel case and such calls are considered deprecated (i.e. the Container's getChildren method is now get_children). Check the server's log thoroughly for deprecation warnings and make the appropriate changes.

QuiX has reached the major milestone of supporting all the popular browsers including Opera, Safari 4 and IE8. The structure of the QuiX API has been re-factored by introducing JavaScript namespaces (i.e. XButton has become QuiX.ui.Button, XMLRPCRequest has become QuiX.rpc.XMLRPCRequest). Of course backwards compatibility is still preserved in order not to break the existing code.
The redraws have been accelerated by using some sort of internal cache mechanism that prevents the core from calculating the same widget parameter twice.
Another great feature combined with the server side Etag support is the ability to persist data sets on the browser side. For accomplishing this kind of functionality QuiX includes PersistJS, a lightweight persistence library, that uses the appropriate persistence mechanism for different browsers including Google Gears, globalStorage, localStorage, openDatabase etc.
Auto-sized widgets are now finally supported. Their size is automatically adjusted based on their contents. Widgets supporting this kind of feature include labels, icons, buttons and boxes. Auto sized boxes require all their children to have fixed sizes or being auto-sized themselves.
Another important improvement is a universal base Widget implementation that now allows integration with non-Porcupine web applications more easily.

Other notable new features and improvements include themes support for QuiX, new optimized transactions, a lightweight rich text editor, new cookie based and database session managers (required for multi-processing setups) and a new Shortcut content class.

This version requires Python 2.5 or later but not supporting Python 3.0 yet. Finally, in order to upgrade your installation to the newest version you will also need to upgrade your web connector to the latest version.
The new connectors are available in the Web Connectors downloads page.
The following wiki pages contain useful information for upgrading to the latest version:

Porcupine upgrade instructions,

How to migrate your applications to the latest version.

Tuning Berkeley DB for high performance web applications

Mon, 01 Jun 2009 00:00:00 +0300

Extensive stress tests of the new Porcupine version using different configurations for Berkeley DB have shown some interesting results. Here are some tips for configuring Berkeley DB in order to get the most out of it when used for web applications.

1. Use the DB_TXN_NOWAIT flag for transactional operations. This option minimizes the number of the write locks at a given time since transactions do not block waiting for the next lock to become available, but instead they are aborted releasing all the locks that they currently possess. This option also eliminates the need for a deadlock detector because no transaction will ever block waiting for a lock acquired by another, resulting in a deadlock-free database. Once a lock is not available the transaction is immediately aborted and then retried.
Of course this approach requires that you wrap all of your transactional operations in a special wrapper (a Python decorator) that is responsible for retrying each transaction whenever a lock is not granted for a given number of times using some kind of exponential/linear layoff between retries.

2. Drop the D out of ACID for transactions that need not to be durable by using the DB_TXN_NOSYNC flag. Such type of transactions include the session state or even better all transactions if you have some kind of synchrounous replication to multiple nodes for fail over capabilities.

3. For transactional cursors use an isolation level of 2 whenever possible by using the DB_READ_COMMITTED flag. This increases the overall write throughput because data items read by this type of cursors can be modified or deleted prior to the commit of the transaction for this cursor.

4. If you have many requests competing for updates on the same resource consider using a semaphore for limiting the maximum number of concurrent transactions per process to a specific number. Tests have shown that under these conditions and without a semaphore, single process server instances achieve a better throughput than the multi process instances. This is happening because on a single process server instance the maximum number of transactions is kept low enough for transactions not to compete hard one against another, resulting in less retries.

5. I guess that last one is well known. Keep that data and log files on separate disks.

The Porcupine source code repository has now moved to github

Thu, 16 Apr 2009 00:00:00 +0300

The Porcupine Subversion repository will no longer be maintained. I have recently moved the repository to github. There you can find all the new exciting features for the upcoming release (hopefully to be released this month) including:
- Multiprocessing support for Python 2.6
- Database indexes
- QuiX namespaces with backwards compatibility i.e. "Label" is now "QuiX.ui.Label"
- Support for QuiX themes
- A lightweight rich text editor
- Support for Opera 9, Safari 4 and IE 8
- Conditional Etag support
- Persistent data sets on the client side using PersistJS combined with the 304 (Not Modified) response code for POST requests (remote method calls).
- Redesigned transactions
- Database and cookie based session managers
- New optimized web connectors (including out of the box support for mod_wsgi)
- and many more...
The new repositories can be found at http://www.github.com/tkouts.

Key-value databases for scalability?

Mon, 23 Feb 2009 00:00:00 +0200

Recently, RWW posted a very interesting article about the new breed of emerging databases for massively scalable internet applications (http://www.readwriteweb.com/archives/is_the_relational_database_doomed.php). Examples of these kind of databases include Amazon's Dynamo and their newest release called SimpleDB, CouchDB, HyperTable, and of course Google's AppEngine Datastore which is based on Big Table.

I think this article is quite predictive about the future of databases and cloud computing. I believe that the two biggest problems that relational databases are facing are their inability to handle efficiently semi-structured data and the lack of multi-node scalability (scaling out to hundreds or even thousands of nodes). The need for scaling as you grow is an essential requirement for cloud computing.

On the other hand, I too don't believe that relational databases are doomed in anyway. They will be dominating the market for a long time yet.

To slots or not to slots?

Wed, 18 Feb 2009 00:00:00 +0200

In one of the previous Porcupine releases I decided to add the Python's __slots__ class attribute to every class which is schema related. This was done in favor of smaller memory consumption since these classes don't have a dictionary (the __dict__ attribute) for keeping instance variables.

But practice has shown that this addition was a move against flexibility. Whenever a schema update is required, this also requires database updates in order to add new or remove old attributes. Apart from this, the __slots__ attribute is known for breaking multiple inheritance.

Therefore, I'm thinking of removing the __slots__ attribute from all schema related classes in the upcoming version. Whenever a schema update is required, this will only be done at the Python class level, without requiring database updates. But then, in case of an attribute removal the persisted objects will continue to have the specific attribute. So when will this attribute be actually removed? The answer is the next time the object is updated.

I'm much more in favor of a flexible database that is self adjusting to schema updates than having a rigid schema that requires database updates every time it is changed (see relational databases). The natural fit for dynamic language is a dynamic self adjusting storage.

NetBeans 6.5 Python IDE

Mon, 19 Jan 2009 00:00:00 +0200

The last month I have been using the NetBeans IDE for doing Python and JavaScript development and I must say that I'm pretty satisfied. This is the first time I use an IDE other than Eclipse, for more than two weeks.

Just like with every new release there are some minor issues but overall I think this is a very promising Python IDE and eventually will improve with each new release. After one month of use here are the pros and cons:

Pros:

- Very good code analysis tools
- Effective auto-completion
- Good Python debugger

Cons:

- Editing performance is inferior compared to this of Eclipse
- The SVN plugin automatically adds any new files added in the project folder (you have to add them to svn:ignore manually in order to avoid adding them to the repository)
- The file statuses are not updated when using the command line version of SVN (a "Refresh" option would be handy)
- The first time launched it failed to index my "site-packages". I had to move this folder temporarily in order to successfully index the libraries of the standard CPython installation

FileTrack v0.1-RC3 is released

Mon, 22 Dec 2008 00:00:00 +0200

The latest release of FileTrack, a Web enabled communication logger, is now available for download. This release is mainly a compatibility release. I have included all the required changes in order to comply with the latest Porcupine release (0.5.2).

This release also includes a fix for not being able to remove persons from the CC list of a single log entry, but also a critical patch for the "porcupine.administration.codegen" package.

Download the application's package and then follow the installation instructions to install it.

For those still using Porcupine v0.5 you can now safely upgrade to the latest version and then also upgrade to the latest version of FileTrack using the standard installation procedure for ppf files.

Porcupine v0.5.2 is released! Now with wider browser support

Thu, 04 Dec 2008 00:00:00 +0200

Porcupine v0.5.2 is finally here. This release includes the brand new version of QuiX supporting the latest releases of Firefox, Safari and Chrome browsers but also introduces a couple of new exciting enhancements. A popular request for QuiX has always been an effects module. This release has a new small effects module that initially supports fade, wipe and slide effects. Furthermore, the newest version includes an enhanced list view widget implementation with no more wobbling headers and great support for large datasets by using asynchronous rendering. Finally, the base widget class has a new "query" method for performing advanced queries on the widgets hierarchy and a new auto complete widget contribution.

On the server side the "db_backup.py" utility is renamed to "porcupineadmin.py" and the database recovery is no longer attempted during the server start up process. Database recovery is now done by using the "porcupineadmin.py" utility with the "-c" switch. This allows multiple processes to access the database at the same time. Consequently, prior to installing or uninstalling an application with the "pakager.py" utility no longer requires the server to be stopped and then later re-started.

This release also includes a new redesigned transaction sub-system. All transactional web methods must be marked as such by using the special "@db.transactional()" decorator. This decorator must always be declared right after the main web method decorator (i.e. webmethods.remotemethod). If you need transactions inside Python Server Pages create a function in the page and make it transactional by using the the "@db.transactional" decorator.

Before reaching the milestone of release 1.0, for each new release the Porcupine API is not guaranteed to be backwards compatible but I'm doing my best to make these changes as harmless as possible. Gradually, the Porcupine API will become fully aligned with PEP 8.

The following wiki pages contain useful information for upgrading to the latest version:

Porcupine upgrade instructions,

How to migrate your applications to the latest version and the

Change Log for a detailed list of the new features, bug fixes and enhancements.

Browsers roadmap

Tue, 07 Oct 2008 00:00:00 +0300

The last month mabber
seemed to be facing some major problems. Therefore, I wasn't able to chat with you online. This week it seems to be back online. When I accessed my account I saw all the initiated chat sessions that I had missed. Two of them were about universal browser support for QuiX and the roadmap behind this.
I don't know when QuiX is going to be ported to Konqueror but I know that Opera support has to be put in place ASAP after implementing the first set of the scalability improvements.
Thus, the Opera fanatics (including my friend amusic) can stay assured that soon they won't have to switch to another browser in order to use Porcupine and QuiX based applications.

Why Safari support has become important

Wed, 24 Sep 2008 00:00:00 +0300

The next version of Porcupine - hopefully to be released in October - will include the new version of QuiX that supports the Safari browser. When I started developing this new feature, I never realized how beneficial it would turn out in the mean time.

After having done some tests on iPhone, it turns out that you can run full featured QuiX based applications on mobile Safari. Ideally, you will need to write a separate QuiX based front end for your iPhone application, using Apple's guidelines. Having a desktop on a small screen is not usable and there are a lot of unsupported actions like double clicks and drag and drop.
The RPC interface of your application can be shared between both the dekstop and the mobile versions of your application.

Then Google releases Chrome, a new browser that is based on Webkit, the same rendering engine that Safari uses. With some minor tweaking I managed to run the Porcupine desktop in Chrome within a couple of hours. Therefore, the next version of Porcupine is going to support Google Chrome too.

For those who can't wait to test these new features, you can check out the latest development version.

Running Porcupine on SMP systems

Wed, 03 Sep 2008 00:00:00 +0300

The last days I have been wondering what it takes to have multiple Porcupine processes running on SMP systems, as the first step towards scalability. Since almost all of the modern CPUs are multi-core and due to the Python's Global Interpreter Lock, in order to take full advantage of a CPU's horsepower is to have multiple Porcupine processes (sub-processes to be precise) all accessing the same database.

The good news is that Berkeley DB allows different processes accessing the same database. But the current implementation has a minor fault; the database environment is opened using the db.DB_RECOVER flag. Each time Porcupine starts a database recovery is attempted. The problem with this procedure is that it can only be initiated from a single threaded environment (see what happens if you try to start Porcupine twice without having stopped the first instance). Therefore, database recovery should only be performed using an external script after having stopped all Porcupine services (processes).

The next thing I had to consider is what gets shared between these processes. The ideal scenario says "nothing". The first issue that I need to deal with is the session manager. Since the Porcupine session manager is extensible by sub-classing the GenericSessionManager class, then one can write a new session manager that persists the sessions in the database. Another alternative is to design a new session manager that keeps the session state inside cookies. The latter has two main drawbacks; it requires cookies to be enabled on the browser side and the length of each request is growing proportionally along with amount of data written. But on the other hand, no disk access.

Last but not least, the object cache. The current object cache is useless when we are talking about multiple processes. The memcached project seems to be the right fit although not as portable as writing a native Python alternative.

The updated recipe manager tutorial is online

Mon, 11 Aug 2008 00:00:00 +0300

The recipe manager tutorial is updated in order to reflect the latest Porcupine API changes. This tutorial goes through all the steps required for building and
deploying a simple Porcupine application from scratch. The sample application is a recipe manager used for storing and retrieving cooking recipes.

Most of the changes introduced are focused on the replacement of the old deprecated servlet classes with the new Web method decorators. Due to the fact that the the latest Porcupine release requires no heavy XML file editing, the tutorial has been greatly simplified resulting in a much more understandable form.

QuiX custom widgets

Tue, 05 Aug 2008 00:00:00 +0300

I have just created a new downloads section dedicated to QuiX custom widgets. I have initially included two QuiX custom widgets; a ruler and a flash video player.

If you have already created one or more QuiX custom widgets and you want them published, I would be very excited to include them in the existing list. Just email me including a link to your site and/or if you send me the source code users can download your widgets directly from the inno:script web site.

Porcupine and Firefox 3

Wed, 16 Jul 2008 00:00:00 +0300

The latest official release is not compatible with Firefox 3. This is because Firefox 3 has added the "charset" directive in the Content-Type HTTP header. As a result Porcupine cannot detect an XML-RPC request initiated by Firefox 3. Here is a quick fix.

Open with an editor the "porcupine/core/http/request.py" file and replcace line 74 with the following code:

if self.serverVariables['CONTENT_TYPE'][:8] == 'text/xml':

That's it. Save the file and re-start Porcupine.

inno:script is now having a new web site

Mon, 14 Jul 2008 00:00:00 +0300

The new web site is far more friendly for search engines and more consistent than the old one in terms of putting things where it should be and not having pieces of relevant information scattered in different sections. I hope you like the new design.

The forum has been replaced by a Google discussion list, being the new preferred channel for getting support. The inno:wiki - although being partly outdated - is renamed to porcupine:wiki. Given the fact that I'm actually running three demanding commercial projects based on Porcupine, me and my small team are doing our best to keep it up to date.

Last, don't forget to update your bookmarks!

FileTrack v0.1-RC2 is released

Mon, 19 May 2008 00:00:00 +0300

The new FileTrack release is available for download. FileTrack is a Web-enabled communication log, keeping track of all your inbound and outbound documents. It supports multiple logs, auto-archiving of older entries, and generates simple reports based on multiple criteria. One or more log entries, contacts, or documents can be grouped together into an issue for easier monitoring.
Apart from a couple of minor bugs being fixed this release also includes all the changes required for making it compatible with the latest Porcupine version.
Download it and then follow the installation instructions to install it. Due to the latest desktop schema updates, the upgrade procedure is not so easy as doing a clean install.

If you need to upgrade to the latest version of FileTrack, you also need to upgrade Porcupine to the latest version. The steps required for upgrading are:

First upgrade Porcupine to the latest version by using the standard procedure (do not forget to stop the service before attempting the upgrade) as described here. If you are running Windows it is recommended that you use an external uncompress utility such as WinRar. Using the built-in Windows zip handler will result in an non working server. After upgrading, the server won't start because of the current FileTrack version. The upgrade package installation will exit with errors. Ignore them.
Download the new FileTrack ppf file and install it using "pakager -i -p FileTrack-0.1-RC2.ppf". During the installation process you will be asked if you want to keep a backup of the previous FileTrack source code. You are advised to do so only in case you have modified the code. The package installation will not be completed. Just ignore any errors for the moment.
Download the "upgrade-0.5.ppf" package and install it using "pakager -i -p upgrade-0.5.ppf". If you are using the Porcupine source this download is not necessary. This file will normally reside on the installation's root folder after unzipping the source upgrade. On the other hand, this download is required for those who have installed the win32 executable. This time the package installation should exit normally.
If you reached to this step then you have succesfully upgraded Porcupine and FileTrack to their latest versions. Just to make sure, you can now install again the latest FileTrack package.

QuiXSampler v0.5 is released

Fri, 09 May 2008 00:00:00 +0300

The new release of QuiXSampler is available for download. Most of the changes introduced can be found in the splitters' section, since the splitter widgets now derive from boxes.
QuiXSampler can be downloaded from the Porcupine applications' downloads or viewed online using the newly upgraded Porcupine demo.
In order to install it, consult the inno:wiki.

Small patch for Porcupine v0.5

Thu, 08 May 2008 00:00:00 +0300

This small patch fixes the size of list views contained in windows opened while exploring containers on the Porcupine desktop. This is mostly noticeable while the list views have their scroll bars displayed. Download the following file and copy it inside the "org/innoscript/desktop" folder.
Download patch

Porcupine v0.5 is released. More Pythonic, more productive.

Sat, 03 May 2008 00:00:00 +0300

This release is a major breakthrough for Porcupine. The two main new concepts introduced on the server side are the services and the web methods. Porcupine's architecture is now based on configurable services running over a common object database. Currently, the supported service types include an asynchronous network server and a scheduler used for executing Python code at predefined fixed intervals. In the upcoming releases there are plans for new service types to be added including persistent queues, loggers etc.
Web methods have replaced servlets completely and they are actually smart Python decorators which allow you to add methods to content classes dynamically (a technique also known as 'monkey-patching'). These methods become directly accessible over HTTP and they are mainly used for serving all kinds of UIs and RPC requests. Consequently, this release does dot include servlets of any type meaning that you have to migrate your applications manually.

Another major productivity enhancement is that this release no longer requires heavy XML file editing. Thanks to web methods, the "store.xml" is no longer used and the "config.xml" files for each published directory can now contain smart registrations with regular expressions matching becoming a powerful rewriting engine.

Other improvements include support for pre-processing filters, more memory efficient object sets and type safe data types.

On the browser side QuiX has become less resource intensive by using a pooled set of XMLHTTP objects and improved garbage collection. Last but not least, the scroll bars bleed through issue on MacOS Firefox browsers is now resolved.

The upgrade process is the usual and is quite straight forward. The following wiki pages contain useful information:

Porcupine upgrade instructions,
How to migrate your applications to the latest version and the
Change Log