Category: Cation

05/09/05

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.

04/27/05

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

Designing from the outside in

Link: http://jtauber.com/blog/2005/04/27/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 jtauber.com 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]
    \        /
     \      /
  [EnDue][Junct]
     |
     |
[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.

02/25/05

Permalink 03:33:21 pm, by fumanchu Email , 344 words   English (US)
Categories: IT, Python, Dejavu, Cation

Where to put the locks

I've got to add access control to "Mission Control" (our main business application), and I cannot decide where to do it.

There are two main components: a UI (built on a UI framework, Cation), and a Model layer full of business objects (built on an Object-Relational Mapper, Dejavu).

Part of me wants to build the controls into the business objects themselves, since that's really what needs to be protected. I don't care if someone can access a page if they can't see any data on it (or add any data through it). It wouldn't be difficult to enforce, because all the business objects already subclass dejavu.Unit, the base class for the ORM. The downside is that Dejavu doesn't currently have any concept of users or access controls. Any user context, therefore, would have to be passed into Dejavu from outside. This wouldn't be too hard, since every Dejavu session checks out its own Sandbox object--I could just stick a reference to the access-control library into the Sandbox. I'd probably end up leaving the default Sandbox as is, and write a new SecureSandbox class, then decide between the two via a config parameter.

Writing the locks into the Model would be nice, because, in general, those change less often than the View. When new features are added, having the locks in the View code means a higher probability of forgetting to test for permission.

It would also be nice for management by end-user admins--they tend to understand "you can see Mission Trips but not Projects" better than long lists of event descriptions like "Show the Zip Code of the Primary Addressee on a Group Scheduling Report (but not a Group Scheduling Calendar)".

But another part of me wants to put the locks in the View. It would allow finer-grained permissions, and allow locks on behaviors which don't involve persisted business objects. It would also be better-integrated, since the View layer already interacts with authentication code in the webserver. There's also a lot of precedent, in that most ORM's don't manage permissions.

Hmmmm...

02/05/05

Permalink 02:59:46 pm, by fumanchu Email , 839 words   English (US)
Categories: IT, Python, Cation

Paraware vs Middleware

Update: I stumbled onto Mike Spille's blog, which talks a bit more (and better) about middleware versus libraries.

Ian Bicking recently promoted the idea of a WSGI reference library, to possibly include the following components (among others):

  • Sessions middleware
  • Logging middleware/library (I assume he meant request logging)
  • Error reporting middleware/library
  • Test frameworks
  • A file application (handling If-Modified-Since, etc)
  • A proxy application
  • Libraries for parsing query strings and all that.
  • Authentication.
  • URL parsers.
  • And maybe a few of the more boring servers, like the CGI server, which will otherwise be homeless (or widely repeated).

Not being the most careful reader in the world, I was thrown by the phrase, "...collaborating on a ... library of WSGI middleware"; I read the list as if he meant each piece would be a middleware component! Of course he did not intend that. Many of the items in the list are WSGI applications, which sit at the end of the software stack.

Some of the items in the list are, in fact, paraware; that is, they parallel the main application. Traditional programming libraries/toolkits are a common example of paraware. They provide functionality by supplying input and output hooks, which are supplied and consumed by the main application:

mylib.set_value(3)
mylib.munge(obj)
result = mylib.get('f')

Middleware, on the other hand, handles/munges a content stream, and sits between at least two other components in a software stack. Middleware is a nasty thing in many environments, because each middleware component must manage I/O of all shared objects, in two directions (both its caller and the next component in the stack). In Python, however (and specifically WSGI), the shared objects are all on the same heap, and can all be passed by reference.

I see problems with writing most of these components as middleware. WSGI has a shot at being ubiquitous because it enforces a set of interfaces and a data model; this same enforcement, however, can also be a liability, since WSGI is not yet ubiquitous. As a developer of a web framework, I have a dilemma: I need to provide the same functionality whether my users use WSGI or not. This means I need to write such components as libraries (so they can be used as paraware) and then wrap them with WSGI boilerplate (so they can be used as middleware). This leads to serious code smell. WSGI's callback structure is complicated enough without me introducing library-code wrappers. Perhaps what we need are generic pieces of WSGI middleware which you can init with a callback from your library code. Hmmm.

Potential components from Cation

I've been meaning for a while now to investigate breaking my Cation app framework down into a set of libraries (instead of the monolithic framework it is today). You can see from the dearth of recent checkins that I haven't done any of it yet. ;) Many of those could be added to a WSGI library (some are already on Ian's list). Here are the ones I'd be most interested in writing:

Top-level error trapping, logging, and pretty printing

I'd like to do this myself because Cation keeps a list of application developers (usernames), and shows full tracebacks in the browser to developers. Ordinary users get a "pretty" error message, and the full traceback goes into the log only. I'm pretty sure a standard library version wouldn't do that. Integrating the usernames into the error handling logic leads me to want to provide this as paraware, since middleware components are usually not expected to interoperate.

Timed, threaded Worker classes for getting things done on a schedule, possibly recurring

This isn't WSGI-specific, and shouldn't be a candidate for WSGI. But it's something I'd like to rewrite in more of a library style, instead of a framework.

Centrally registered and managed requests

For example, this would assist a WSGI application in fulfilling a request to shut down--each active web request (thread) could be sent a shutdown message and kill itself gracefully from outside the application itself.

Data type coercion (both inbound and outbound), including encoding

Since HTML form values are always received as strings, a standard (but overridable) way to convert them into Python values would be helpful. In the other direction, values need to be coerced to strings, put in the encoding of the server (or of the page), and often quoted safely. Again, this would probably need enough customizability that it would be a poor candidate for middleware, but a good candidate for a set of library calls.

Profiling

Classic middleware, meeting a need orthogonal to the actual content delivery, and not needing customization or context.

HTTP uploads.

Something that might on occasion need to be specialized, but ultimately a commodity for 90+% of cases. The standard implementation would be nothing more than a pretty interface over simple (but secure) file management.

That's enough for the next year or so :) Pity I have so many other projects to work on simultaneously.

September 2017
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

Search

The requested Blog doesn't exist any more!

XML Feeds

free blog tool