[TransWarp] Input wanted: Streams, Factories, sessions, etc.

[Phillip J. Eby]

At 10:41 AM 11/18/02 -0500, Ty Sarna wrote:
> > One of the big questions is where to put the interface definitions
> > themselves, though.  They don't quite fit under any of the ideas of
> > binding, naming, config, or even really storage!  Perhaps Ty's idea of
> > 'peak.networking' might make more sense, although even there it's an odd
> > one out when it comes to files.  The interfaces also don't seem ubiquitous
> > enough to deserve placement in peak.api.
>
>Perhaps files would just stay under naming, then?

The implementations can go anywhere, but naming.factories is good enough 
for now.  Actually, I wonder if we shouldn't change that to 
naming.providers, as factories doesn't really mean anything.  When I 
started out the naming package, I expected to make a providers subpackage 
later for contexts like filesystem and LDAP, and there was some reason why 
I thought we also needed factories.  But we don't.


>I think we would want to still support a sendmail() method on the
>session too, for cases where you already have the complete message as a
>string.

Sure.


>My inclination now is "both yes and no", I think.  Transactional
>messaging is useful, but it can also be a pitfall.  I can easily see
>writing code like this:
>
>         ...
>     except UniverseError:
>         # Whoa! We need to page the on-call Quantum Mechanic to
>         # investigate...
>         SendShortMail('KL5-6832', 'Check universe and restart if needed')
>         storage.abortTransaction()
>         sys.exit(42)
>
>     ...
>
>"Oops!"
>
>Now, certainly CTAP and you could create another TransactionService,
>etc.  But messaging about abort-worthy errors seems like a fairly common
>use case, so I'm thinking that perhaps session() should take a parameter
>indicating immediate/non-transacted mode, for situations such as these.

Yeah, JMS does something like that.



>Also, in writing the above, I'm thinking that maybe we should make the
>convenience functions a bit more convenient, and change them to
>storage.beginTxn, etc. We already use the "txn" abreviation elsewhere
>(txnTime, joinTxn, etc), and it shouldn't cause much/any pain to anyone
>if we change it now, before anyone is really using it...

While on that subject, we should also replace the current 'txnSvc' 
attribute in TransactionComponents to be 'joinedTxn', and make 'txnSvc' a 
binding.Acquire(storage.ITransactionService).  In this way, one can do 
something like this:

thing = SomeComponentClas(txnSvc=storage.TransactionService())
storage.beginTxn(thing)
thing.doSomething()
storage.commitTxn(thing)

It would be a quick-and-dirty way to "create another TransactionService, 
etc." for your use case above.  Perhaps we could even have a way to do this:

# Thing is created from given class, and given a separate transaction service,
# and a proxy to the new thing is returned
thingProxy = storage.transacted(SomeComponentClass, args..., kwargs...)

# methods from the proxy do a begin and commit on the wrapped item
thingProxy.doSomething()


Or, more specifically:

storage.transacted(
     naming.lookup("smtp://foo.bar").session,
     # & session args/kw, if any
).sendmail(
     #... sendmail args
)

I'm not sure what I think about this, since it allows separation of 
context; i.e. if you take the proxy and do something with it, you might not 
remember it's operating within a different transaction scope, or that it 
transacts every method call.