Modular Python data server?

[elazich]

I'm new to Flex, AS3 and PureMVC, but reasonably experienced with Python and distributed network apps.

Question: Is there any meaning to the idea of a multicore PureMVC implementation if the target product is a Python+PureMVC based data server?

I had a quick look (and ran) the googeapp server demo, and I see forking request handlers, so unless someone can correct me, I take it that with a Python coded data server there is no requirement for "modularity" from this framework.

Background: I'm considering using PyAMF+PureMVC to simultaneously serve many clients running Flex+PureMVC.  I'd like to keep each server side session as stateless between requests. The server side mediator working with a PyAMF based view. The persistent data store server side would ideally be in Postgresql, so I'm going to look at data proxy tailored to SQLAlchemy to take care of the SQL for me. I'm fine with SQL, but want the flexibility of an ORM.

For sure I'd contribute to the Python PureMVC code base if I think I have something to offer!

Any feedback on my plans are most welcome.

[puremvc]

When you think about the need for modularity, and specifically, a MultiCore version of the framework it is sort of tied to what you want to have happening in that server.

When you think in terms of shallow-reaching request handling, where you're doing little more than running an app that hauls some data out of a database, templates it and spits it back out, forking the same app for every request would be enough.

But imagine you have a long running modular app sitting there taking requests, and provisioning resources, handling realtime collaboration in a shared space, with server-side agents. Not only stateful stuff but lots of it and not using cookies and a server session object to store it all. Something resembling a J2EE container that has apps running in it all the time that clients connect to.

Modular makes sense on the server if its an enterprise-class problem, I think. But for something like the Blog demo, it might be overkill.

But then again it might not be if you have shallow request handlers, but just gazillions of them.
Rather than register a gazillion commands and proxies, you could have lots of modules, mostly alike inside perhaps, but black boxes to the request handling shell. Based upon the request, it could instantiate the right module, plumb it and send it the request message. When it gets the response, it could send it to a template module (swappable, of course) and when it gets the templated output back it sends it back out as the response.

A setup like this could let lots of people work on pluggable modules without stepping on each others toes if they were all working on one big app.

-=Cliff>

[elazich]

When you think in terms of shallow-reaching request handling, where you're doing little more than running an app that hauls some data out of a database, templates it and spits it back out, forking the same app for every request would be enough.

Hi Cliff, The above paragraph does explain my current requirement.  I do want to avoid state data between requests in my server side handlers. At this stage I also don't see why I'd need communication between my handlers, since I'd let the database enforce it's "rules" upon each handler.  So I'll take that approach for now (forking per connection handler) and maybe look at a threaded version later if needed and if I can easily make the single core framework components re-entrant (see this topic http://forums.puremvc.org/index.php?topic=539.0).

I suppose my initial question could be rephased to ask if the lack of a multicore framework for Python is going to hold me back.  Which you effectively answered for me thank you.

Being a PureMVC newbie (only just skimmed over your idioms doco and hardly written any AS3 code) I'm am still left wondering if a multicore Python implementation would (if it existed) have any beneficial purpose?  Firstly frequent unit testing in Python is just no problem what so ever.  I can appreciate (or guess) that defining cores in a framework context would make good sense in terms of code clarity, but if the only other advantage of the multicore framework is being able to start/stop independent cores and allow them to reliably communicate when running, then I see Python being able to do that already (under a parent/child process system), and at a later date via threads if a few fixes are made to Toby's current codebase.

-Emmett

[puremvc]

Emmett,
The biggest value in any modular system is it let's you break your problem down into discrete chunks that can be easily spec'd, written and managed. In a large application this can really pay off. For one thing its easier to outsource a module as opposed to use cases in a big app. In the latter case, whether outsourced or not, each developer must be familiar with the workings of everything and missteps can cause downtime for the whole team. With modules, a developer's mistakes are well contained within the black box they're working on. In fact they may never need to see the main application at all.

-=Cliff>   

[elazich]

Cliff,  Good answer.  After reading your June 23rd news posting re multicore and AS3, on the term "modular" I was thinking mostly along the lines of runtime capabilities. For sure scalability of all kinds is very nice.  With me not being familiar with FB3/MXML/AS3 I had not considered the common pitfall of letting a Flex/MXML/AS3 browser hosted application grow into a monolithic cross dependent anti-encapsulation monster.  Python is different as far of modular options go, so I have no problems/concerns anymore about using the single core PureMVC framework in Python. Thanks Again.

-Emmett