Re: you got your database in my Python remote objects server

David McNab wrote:
> On Fri, 2007-09-28 at 13:58 -0400, Eric S. Johansson wrote:
>> If folks think it's a good idea, what would it take to validate metakit in a 
>> threaded environment like the one I propose?  Is there a simpler model for 
>> dealing with threaded environments that I'm not aware of?
> 
> Thinking more broadly, have you specifically ruled out using an object
> interface to a common SQL database, such as SQLObject over MySQL?

my only objection to SQL is that it typically takes me five to 10 times longer 
to solve a problem using SQL.  I don't know why I have this mental block but it 
is an absolute horrific experience I wouldn't wish my worst enemy.
> 
> That combination is extremely thread-safe, and gives the remote clients
> an excellent object view of tables, columns, rows etc. And it's pretty
> easy to use.

it's also fat, clumsy, hard to use, etc. etc.  Using an mySQL database in a 
startup where I was a founder and small-scale funder cost me almost $50,000 and 
a year of my life.  I've also used SQL and make a few more projects and they all 
took weeks and months longer than dbm based hacks.  They also didn't run that 
much faster.

> If this doesn't appeal, and you're feeling pretty determined to access
> metakit remotely, then have you figured out a clear definition of
> exactly what kind of 'look and feel' you want on the client side?

I'm sorry that I did not express myself well.  I do not want to access metakit 
remotely.  I want to stick metakit in a framework so that it can be used as a 
component from inside a pyro server.  In other words, metakit encapsulated to be 
local to the server code but remote and indivisible to the client-side code.
> 
> If your 'look and feel' requirements aren't too demanding, then it
> should be possible to set up a Queue-based multithread setup on the
> server, such that only one of the server threads is accessing the actual
> metakit database, and other threads which talk to the remote client
> communicate with this one thread. This wouldn't require any mods to
> metakit or Pyro - just an access layer.

no, that doesn't map to what I'm thinking about.  Again, client side knows 
nothing about metakit.  Server side knows everything.  Requests are effectively 
queued server-side via some form of locking mechanism.  since each request has 
exactly once call and return semantics,a lock makes more sense than a queue.

I'm a strong believer in putting as high a level as possible into a server if 
you're going to use a server in an application.  SQL servers are a botched 
design especially when you look at the volume of traffic going back and forth 
between applications as they do requests and then a half a dozen other steps to 
accomplish the higher-level goal.  In many cases, they would be far better off 
pushing application logic into a core server and keeping the database local.  I 
know SQL has hacks upon hacks to provide this capability but, I'm not willing to 
sacrifice huge amounts of time and and a customer's budget to use those hacks.

yeah, I'm opinionated on this.  It's unfortunate something that goes with the 
territory 

---eric

--

-- 
Speech-recognition in use.  It makes mistakes, I correct some.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the "metakit" group.
To post to this group, send email to metakit <at> googlegroups.com
To unsubscribe from this group, send email to metakit-unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/metakit?hl=en
-~----------~----~----~----~------~----~------~--~---