[TransWarp] Input wanted: addresses, adaptation, and attributes

[Phillip J. Eby]

At 11:08 PM 6/11/03 +0300, alexander smishlajev wrote:
>Phillip J. Eby wrote:
>>Currently, when you bind to an address such as 'pgsql:user:pw at server/db', 
>>you get back a connection object of a "hard-wired" type.  To change this, 
>>you have to specify custom "object factories" in the retrieval context, 
>>which requires fairly intimate knowledge of both what address is going to 
>>be used, and how the underlying name retrieval mechanism works.
>>I'm thinking that it would be better (for some definition of better) to 
>>use adaptation for this.  For example:
>>     myConn = binding.bindTo(
>>         'pgsql:user:pw at server/db', adaptTo=storage.ISQLConnection
>>     )
>
>sounds great.
>
>>A trade-off here is that when you have something that really does need to 
>>be "retrieved", you'll now need to create an actual naming context.
>>For example, the 'import:' scheme that's in PEAK now should really always 
>>have been a naming context, because there are actual objects to be 
>>retrieved by importing.  But for SQL URLs, there isn't anything to 
>>"retrieve".  It's just an address.
>
>>My thought at this point is that naming contexts should retrieve generic 
>>objects according to what kind of context they are, and users then adapt 
>>to specific objects.  So, the 'import:' URL should have a context that 
>>loads the named object (and then you can adapt it if needed).  Pretty 
>>much all other address types would stay as is, just being returned by the 
>>context that looks them up.
>
>i am sorry, i understood almost nothing of all this.

That's probably because 'peak.naming' is too complicated, which is what I'm 
trying to fix.  :(


>till now, i only used importString() to get a well-known class from a 
>well-known module.  of course, that class did implement an expected protocol.
>
>i have no idea about what may be a context for 'import:' scheme.

It's part of 'peak.naming'; if you use bindTo('import:foo.bar') it's like 
using importString('foo.bar').  The difference is that you can use bindTo() 
and lookupComponent() with the import: scheme.

importString() itself is a lower-level tool that's not part of peak.naming.



>and i have no idea how the naming contexts (roughly speaking, 
>binding.Components, right?) may adapt generic objects according to what 
>kind of context they are.

In the peak.naming.contexts module, NameContext and AddressContext are the 
base classes I'm talking about.  AddressContext handles the processing for 
most URL schemes, including import:, pgsql:, ldap:, etc.  Right now, 
AddressContext doesn't actually adapt anything; it calls the address' 
'.retrieve()' method.  I'd like to ditch this and have such "empty" address 
contexts return the address, and allow the address itself to be adapted to 
a desired object.


>>Will this break too much?  Does the requirement of specifying an 
>>interface for a binding (or lookup) seem too strict?
>
>does this mean that each config.getProperty or binding call will have to 
>be rewritten with 'adaptTo' argument?  if yes, that would hurt, for sure.

Pretty much any binding call that uses URL schemes other than 'import:' or 
'config:'.  getProperty would be unaffected, as would binding lookups using 
'import:' or 'config:', because they already use (or would use) a context 
to do retrievals, instead of the address having a 'retrieve()' method.

So, the affected schemes would be: smtp, uuid, ldap, sybase, pgsql, gadfly, 
logfile, logging.logger, lockfile (and its variants), win32.dde, http, ftp, 
https, file, pkgfile, zconfig.schema, and shellcmd.  Any binding using 
these schemes would need an explicit adaptTo or an explicit adapt(), 
otherwise they would just return an address object.