[TransWarp] RFC: PEAK package organization, continued

[Ulrich Eck]

Hi Phillip,

> I really don't think it's that central.  I think it's pretty *basic*, and
> in the tutorial it'll probably be the first part of the binding package I
> cover.  That's because it's also fairly *ubiquitous*, in the sense that
> you'll tend to at least stick a setupModule() call at the end of a lot of
> modules.  But *central*?  Not really.  It seems to me that after a brief
> period it disappears from consciousness altogether; it's no more central
> to your working focus than class inheritance is.

If so, your right moving it to binding.xxx

> So, I see the connection drivers themselves as being somewhat irrelevant
> if we have an API that sufficiently masks their differences.  The idea is
> that the deployment package is focused on masking deployment differences,
> of which database drivers are one.  Conversely, the DataModel system (or
> whatever it will end up looking like in PEAK), is focused on specifying
> models that are part of the application, rather than part of its
> deployment environment.  It would almost belong more in the model package
> than in the deployment package.

sounds good .. we'll see :)

> Not a problem.  I don't recommend anybody try to follow what's going on
> in the restructuring right now.  It will settle very soon, though, as I
> don't think there's anything else I'm going to propose as far as
> restructuring.  Everything I've got in my head right now is either about
> adding new facilities to PEAK (such as the AppUtils and MetaDaemon
> ports), or about documenting the existing stuff.

:)

>
> Well, there's also the database package refactoring.  But that's not
> going to play a part in PEAK 0.2, which will simply not provide any
> database facilities whatsoever.  PEAK 0.3 will probably focus simply on
> providing uniform access to ManagedConnections for Python DBAPI drivers,
> and not provide a DataModel layer as such.  "Uniform access" is
> unfortunately a rather big project, because this means dealing with crap
> like the fact that different backends take different parameter syntaxes!
> Developers used to JDBC and even Perl DBI are probably not going to find
> that kind of variation acceptable.

there is much work todo ..

We decided to take the current DataModel from TW and merge it with our
modifications and port it to peak till the new stuff arises ..

>
> Anyway, functionality corresponding to TW's record-oriented data
> management will probably not be until 0.4.  If you decide to make use of
> PEAK before that time and want to keep the TW stuff, you'll need to port
> it.  Since the model and binding stuff isn't changing fundamentally, you
> should find it a matter of mostly doing search-and-replace operations.
>

yup

thanks


Ulrich Eck
---------------------------------------------------------------------------
net-labs Systemhaus GmbH
Ebersberger Str. 46
85570 Markt Schwaben
fon:   +49-8121-4747-11
fax:   +49-8121-4747-77
email: ueck at net-labs.de
http://www.net-labs.de