• View
• Edit
• History
• Print

PyWacket

The PyWacket project is intended to integrate common desktop functions between different OS ( Linux, Windows, Apple ) installations running on the same or different machines using primarily Python components. The idea is to 'weave' different machine together seamlessly.

At this point, the focus of PyWacket has shifted to developing a Python semantic wiki similar to Semantic Mediawiki which will power the Semantastic site.

1.  Usage Scenarios

It's important to develop a concrete set of usage scenarios. It helps to define what is essential versus nice-to-have and limit 'scope creep' that seems to be innate in every software project.

An example of requirement is integrating email clients across different machines, particularly those pesky "email sent" messages strewn across a dozen machines/operating systems/email apps. It should work for selected email clients on both Linux and Windows, and perhaps the Mac as a nice to have. Another big plus is the ability to run on netbook computers ( Windows/Linux ) as a sort of desktop for small python applications as well a email integration.

Other examples include shared/synchronized links and documents, versioning of documents, common system management and security tools, and dozens of other potential desktop needs. These need to be work out in greater detail, at least for the desktop part of the project.

There are two sets of Pywacket usage scenarios: one for the desktop, the other for a semantic/knowledge wiki application ( that is, Semantastic ). The two usages overlap in that knowledge about desktop configuration and local network services can be representing in the semwiki. In a utopian version of this thing there will be rule engine to maintain internal consistency and trigger workflows.

2.  Foundation Technologies

Various Python foundation technologies are implied by the few requirements listed above.

In one version, there would be a common server to replicate data across several machines: in another version, there would be peer-to-peer synchronization. Probably implementing both is the correct answer, first the peer-to-peer framework and then the server framework.

• PyWacket Servers - Twisted and other Python software running on the server ( probably behind Apache ). The server is a on public network so security is paramount. The server version might have Subversion and perhaps some curses capability through SSH.
• PyWacket Peer-to-Peers - workstations running "localhost" clients/servers on a private network. Examples include Twisted/PyGTK clients with Twisted daemons, maybe lighttpd, no Apache, possibly running in conjunction with a Bazaar repository. There are many many options.

3.  Minimal Binary Dependencies

One overall caveat is that all binary dependencies can be satisfied on three different types of operation systems, four types including Linux server ( or six type if one includes Android and iPad systems ). In some cases, it might be OK because the application will only need run on Linux, such as the icecast streaming media server, which I would never under any circumstances run on Windows. Or, major binary dependencies can be satisfied in one big chunk, like Cywin for Windows. However, in general, custom binaries are out of the question for this project.