Categories: IT, Architecture, Linnaeus Award, Python, Cation, CherryPy, Dejavu, WHELPS, WSGI, Robotics and Engineering

Pages: << 1 ... 7 8 9 10 11 12 13 14 15 16 17 >>


Permalink 02:13:21 pm, by fumanchu Email , 45 words   English (US)
Categories: IT, Python

Content-type: text/x-json

Update: it really should be "text/x-json", not "text/json".

Funny that I haven't seen anyone recommend this before. It sure would make XMLHttpRequest parsing a snap, on both ends.

I think I'll try using that in my CherryPy JSON library.


Permalink 11:18:48 pm, by fumanchu Email , 200 words   English (US)
Categories: Python, WSGI

Discarded WSGI wrappers

Last year I threw together a preliminary mod_python handler for WSGI (with much help from PJE, of course). Looks like Steven Armstrong has polished it up a bit. Good show!

Here's another adaptation. Anyone interested in consolidating them so a standard can be placed in wsgiref itself?

I've also been thinking about an ASP handler again. Now that I've moved my own Python ASP apps to using a URL rewriter, one of the two strikes against an ASP handler is gone.

The other strike was that the server doesn't have any facility for telling the application whether it's being run multithreaded or multiprocess. The mod_python wrapper dealt with this (in versions less than 3.1) by checking PythonOption directives for the necessary parameters; I think an ASP wrapper could do the same by requiring all ASP+WSGI apps to stuff that metadata into Application.Contents within a mandatory Global.asa. Ugly, but it would nicely round out the WSGI-server offerings.


Permalink 04:25:31 pm, by fumanchu Email , 370 words   English (US)
Categories: IT, Cation

RESTful re-treat

I've been looking around recently at Python web frameworks (again). But I keep remembering the reasons why I wrote Cation in the first place:

  1. When all of your users access network files using a Windows network password, it's very nice to be able to use the same password for a web application—this means using IIS on the server side in its "Integrated Windows authentication" mode. Using IIS means rejecting the vast majority of all existing web frameworks.
  2. A persistent server process is a Good Thing, so "dumb" CGI is right out.
  3. Pure ISAPI handlers for IIS generally suck, due mostly to requiring the deployer(!) to compile a DLL, or costs which I-as-framework-developer don't wish to foist upon others.
  4. ...which leaves ASP. Fortunately, Python can be used as an ASP language. Unfortunately, IIS/ASP has no built-in URL rewriting, so you need a separate .asp file for each URL you expect to serve.

I've been re-examining that set of assumptions lately, because I want to develop more RESTful representations of our data. Many of my current web forms suck, because they pull large sets of data in the interest of not-reloading-the-page. The prevalence of XMLHttpRequest is leading me to investigate alternatives.

The problem with a more-RESTful approach is that I'm currently stuck with the side-effects of #4, above; each URL needs a separate .asp file. So, if I want to publish the URL /app/directory/45987, I've got to create a file named /app/directory/45987! This is Not Good. In addition, I don't think I can serve a resource without a file extension (like ".asp"), but don't quote me on that one.

Therefore, it looks like the choices are:

  1. Ditch IIS and work solely with Apache. This may make some users mad when they get passwords out of sync. But it would mean I could drop my web framework completely and develop a REST+JSON plugin for an existing, major Python framework.

  2. Bite the bullet and use ISAPI rewriting. I found a simple ISAPI rewriter today: ISAPI_Rewrite, which has a freeware "Lite" version.

Tough choices like this make me pine for my own personal hypnotoad.

Permalink 09:48:52 am, by fumanchu Email , 17 words   English (US)
Categories: IT

The new VAIO must-have accessory

For those new ultralight, compact, "portable" VAIO's. Combination docking station and wheeled luggage. Only $599.99! Supplies are limited.

Hand truck for VAIO laptop



Permalink 11:37:01 pm, by fumanchu Email , 80 words   English (US)
Categories: IT

The Software shall be used for Good, not Evil


From the JSON-for-Javascript library:

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The Software shall be used for Good, not Evil.


Permalink 12:13:53 pm, by fumanchu Email , 107 words   English (US)
Categories: IT, General

Google Bible

You know that cool preloading that Google maps does (where, when you drag the map, some of the surrounding tiles have already been loaded and instantaneously pop into view)?

We need that for an online Bible. I'm tired of getting a chapter at a time. If studylight would do that and include their Strong's numbers, I'd never go anywhere else (hint, hint).

Heck, we need that for lots of large documents.


Permalink 10:48:30 am, by fumanchu Email , 376 words   English (US)
Categories: IT, Dejavu

Outgrowing databases

Daniel H. Steinberg gives a summary of Adam Bosworth's recent keynote at the MySQL User's Conference 2005:

If you build an open source stack that delivers globally available information, how do you massively distribute it and cause it to scale? Bosworth said you need to limit your queries to those that can be easily implemented by everybody and those that can be handled by a single machine. This requires that your queries run at the item level. This might feel odd to those used to dealing with databases, as this means you are not likely to perform joins, aggregations, or subqueries. There is plenty of SQL that cannot be supported.

This is one of the design artifacts of Dejavu: if your domain model requires complicated joins, unions, or subqueries, it's better to refactor your model than to fight with data aggregation queries. Dejavu forces you to do so, in fact, because I didn't care to provide an object-to-SQL translation for such queries.

Refactoring may be painful, but is necessary for growth in almost any application. Best to do it up front than to be lured into fragile schemas, only to be forced to refactor or die later on.

Working backwards through the article:

Bosworth predicts that RSS 2.0 and Atom will be the lingua franca that will be used to consume all data from everywhere.

I've been thinking lately about writing a generic RSS interface for Dejavu. A simple object-property reader/writer would be a cake-walk; security would be the tough bit to design.

Imagine if you can query any data that is available anywhere in the world. Bosworth said that what this requires is a single, simple, open wire format for items. The format needs to be simple for any P programmer to deliver and any JavaScript programmer to consume.

Hm! Exactly where I've been going with Lyrica—I'm working hard to push as much as possible into Javascript on the client. The viewer will certainly be Javascript-only, with an option to traverse local files, so that the server connection isn't necessary once you've built your slideshow.

Permalink 10:09:39 am, by fumanchu Email , 286 words   English (US)
Categories: IT, Python, Dejavu, Cation

Designing from the outside in


...extracting a re-usable framework after the fact struck me as interesting because that's really what's happened with Leonardo. Two years ago, I wrote a little wiki-like script in Python in order to enable editing of content on from a browser. I then decided to expand it just over a year ago to include a blog. Now, as more features are being requested, an underlying web framework is emerging that could very well be useful outside of running a wiki or blog.

The same thing happened with Cation (a web framework) and Dejavu (an ORM). I was tasked with rewriting our core business app—two years ago, it was a procedural CGI app written in Visual Basic 4! When I rewrote the whole thing in Python, I started by isolating Cation+Dejavu into their own layer. After about six months I then separated Dejavu from Cation. In addition, I made a middle business-objects layer called "EnDue", which the final app, "Mission Control" is built on. There's also a wiki-like app called "Junct" which I built on top of Cation and Dejavu. So the tree currently looks like this:

[Cation]  [Dejavu]
    \        /
     \      /
[Mission Control]

I've also got "test apps" for Dejavu and EnDue (well, I'm still writing the one for EnDue...I think I'll model the business of the beard-and-stone salesman from "Life of Brian" ;) Any good names for such a business?).

Anyway, the real point I want to make (and have made before) is that I'll probably replace Cation with another web framework sometime this year...but I wouldn't have known which existing framework to pick if I hadn't written my own first.


Permalink 03:45:18 pm, by fumanchu Email , 107 words   English (US)
Categories: IT

How I spent my Spring Break

I set up all this:

Network components in El Paso

  1. The old Merlin phone system, which was removed in favor of...
  2. The new Avaya digital phone system, which talks to the phones in our San Diego office over...
  3. The new T1 router, which replaces the old DSL, and serves...
  4. The LAN clients, via this hub, firewall/router, and switch, which have a couple of green cables running to...
  5. The new VPN server, which I described how to set up here and here.

<< 1 ... 7 8 9 10 11 12 13 14 15 16 17 >>

August 2018
Sun Mon Tue Wed Thu Fri Sat
 << <   > >>
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31  


The requested Blog doesn't exist any more!

XML Feeds

free blog software