[Twisted-Python] twisted.vfs issues

[James Y Knight]

On Sep 28, 2005, at 8:04 PM, Jp Calderone wrote:
>  twisted.vfs should not import things from or depend upon  
> twisted.web2:
>
>    * web2 is unreleased
>    * web2's APIs are unstable
>    * vfs is more generally applicable than web2    * web2's stream  
> abstraction is not generally agreed upon
>
>  If you like, we can talk more about how this interface should  
> work.  However, my first inclination is to say that it should use  
> the existing producer/consumer APIs.  While these are not the best  
> APIs, they are used widely throughout Twisted, and therefore this  
> will give the greatest usability to the resulting VFS code.  While  
> there are adapters between these APIs and web2 streams, I still  
> recommend against web2 streams for the reasons mentioned above.
>

Twisted.vfs should not depend upon a module in twisted.web2 when  
twisted.vfs gets released. However, it is okay for it to depend upon  
that stream _code_ if it gets moved into twisted core before vfs is  
released. The idea all along has been to move t.w2.stream into  
twisted core when it is stable and useful. So I wouldn't worry about  
tearing it out of t.vfs quite yet.

Now, my first inclination is that the current block API *is* the  
right primitive for a file.

Also, in particular, making it use the old producer abstraction as a  
primitive is just asking for trouble. As the producer abstraction  
lets the producer send data asynchronously at any point, it becomes  
almost impossible to do a relatively simple operation like reading a  
part of a file. That is why, for web2, I had to drop it and make a  
new API that has the consumer request the data. I think the same  
reasoning applies here.

Again, I think that all requests for tearing various adapters and  
other bits out of twisted.vfs are currently completely premature. At  
this point in its development, it is critical that adapters for many  
different systems are created, to make sure that vfs has the  
appropriate abstractions and APIs to handle all use cases. And given  
that vfs is itself heavily under development, it makes no sense to  
request that said adapters be adopted upstream in each other project,  
yet.

James