Main Page | Class Hierarchy | Alphabetical List | Class List | File List | Class Members | File Members | Related Pages

IConduit Struct Reference

Inheritance diagram for IConduit:

IResource IConduitSource IConduitSink Conduit SocketConduit FileConduit List of all members.

Public Types

enum  { Eof = -1 }

Public Member Functions

void attach (IConduitSource input)
void attach (IConduitSink output)
int read (IBuffer target)
int write (IBuffer source)
IConduit copy (IConduit source)
IConduit flush (IBuffer source)
IBuffer createBuffer ()
bool isReadable ()
bool isWritable ()
bool isSeekable ()
protected void closure ()
Object getLock ()
void setLock (Object lock)
void acquire ()
bool acquireIfOpen ()
void close ()

Private Member Functions

int reader (void[] dst)
void bind (IConduitSource next)
void unbind ()
int writer (void[] src)
void bind (IConduitSink next)
void unbind ()

Detailed Description

Conduits provide virtualized access to external content, and represent things like files or Internet connections. Conduits are modelled by mango.io.model.IConduit, and implemented via classes FileConduit and SocketConduit.

Additional kinds of conduit are easy to construct: one either subclasses mango.io.Conduit, or implements mango.io.model.IConduit. A conduit reads and writes from/to an IBuffer in large chunks, typically the entire buffer.

Definition at line 56 of file IConduit.d.


Member Enumeration Documentation

anonymous enum
 

Declare the End Of File identifer

Enumeration values:
Eof 

Definition at line 64 of file IConduit.d.


Member Function Documentation

void attach IConduitSource  input  ) 
 

Attach a filter to the IConduit input. The filter is invoked via its reader(void[]) method whenever a block of content is being read; the void[] array represents content destination. The filter should return the number of bytes it has actually produced: less than or equal to the length of the provided array.

Filters are chained together such that the last filter added is the first one invoked. It is the responsibility of each filter to invoke the next link in the chain; for example:

class MungingInputFilter : FilterInput { int reader (void[] dst) { // read the next X bytes int count = next.reader (dst); // set everything to '*' ! dst[0..count] = '*'; // say how many we read return count; } }

Notice how this filter invokes the 'next' instance before munging the content ... the far end of the chain is where the original IConduit reader is attached, so it will get invoked eventually assuming each filter invokes 'next'. If the next reader fails it will return IConduit.Eof, as should your filter (or throw an IOException). From a client perspective, filters are attached like this:

FileConduit fc = new FileConduit (...); fc.attach (new ZipInputFilter); fc.attach (new MungingInputFilter);

Again, the last filter attached is the first one invoked when a block of content is actually read. Each filter has two additional methods that it may use to control behavior:

class FilterInput : IFilterInput { protected IFilterInput next; void bind (IFilterInput next) { this.next = next; } void unbind () { } }

The first method is invoked when the filter is attached to a conduit, while the second is invoked just before the conduit is closed. Both of these may be overridden by the filter for whatever purpose desired.

Note that an input filter can choose to sidestep reading from the conduit (per the usual case), and produce its input from somewhere else entirely. This mechanism supports the notion of 'piping' between multiple conduits, or between a conduit and something else entirely; it's a bridging mechanism.

Reimplemented in Conduit, and SocketConduit.

void attach IConduitSink  output  ) 
 

Attach a filter to the IConduit output. The filter is invoked via its writer(void[]) method whenever a block of content is being written; the void[] array supplies writeable content. The filter should return the number of bytes it has actually consumed: less than or equal to the length of the provided array.

Filters are chained together such that the last filter added is the first one invoked. It is the responsibility of each filter to invoke the next link in the chain; for example:

class MungingOutputFilter : FilterOutput { int writer (void[] src) { char[src.length] tmp; // set everything to '*' tmp = '*'; // write the munged output return next.writer (tmp); } }

Notice how the filter invokes the 'next' instance after munging the content ... the far end of the chain is where the original IConduit writer is attached, so it will get invoked eventually assuming each filter invokes 'next'. If the next writer fails it will return IConduit.Eof, as should your filter (or throw an IOException). At the client level, filters are attached like this:

FileConduit fc = new FileConduit (...); fc.attach (new ZipOutputFilter); fc.attach (new MungingOutputFilter);

Again, the last filter attached is the first one invoked when a block of content is actually written. Each filter has two additional methods that it may use to control behavior:

class FilterOutput : IFilterOutput { protected IFilterOutput next; void bind (IFilterOutput next) { this.next = next; } void unbind () { } }

The first method is invoked when the filter is attached to a conduit, while the second is invoked just before the conduit is closed. Both of these may be overridden by the filter for whatever purpose desired.

Note that an output filter can choose to sidestep writing to the conduit (per the usual case), and direct its output to somewhere else entirely. This mechanism supports the notion of 'piping' between multiple conduits, or between a conduit and something else entirely; as with the input-filter case, this is a bridging mechanism.

Reimplemented in Conduit, and SocketConduit.

int read IBuffer  target  ) 
 

read from conduit into a target buffer

Reimplemented in Conduit, and SocketConduit.

Referenced by Conduit::copy(), Buffer::get(), Scanner::next(), and testHttpClient().

int write IBuffer  source  ) 
 

write to conduit from a source buffer

Reimplemented in Conduit, and SocketConduit.

IConduit copy IConduit  source  ) 
 

Transfer the content of this conduit to another one. Returns true if all content was successfully copied.

Reimplemented in Conduit, and SocketConduit.

IConduit flush IBuffer  source  ) 
 

Flush buffer content out to this conduit.

Returns true if all content is flushed; false if writing results in an Eof condition.

Reimplemented in Conduit, and SocketConduit.

Referenced by VersionMango::FileAppender::append(), FlushBuffer::copy(), Buffer::flush(), and Buffer::put().

IBuffer createBuffer  ) 
 

Create a Buffer of a conduit-specific size

Reimplemented in Conduit, FileConduit, and SocketConduit.

Referenced by testHttpClient().

bool isReadable  ) 
 

Returns true is this conduit can be read from

Reimplemented in Conduit, and SocketConduit.

bool isWritable  ) 
 

Returns true if this conduit can be written to

Reimplemented in Conduit, and SocketConduit.

bool isSeekable  ) 
 

Returns true if this conduit is seekable (whether it implements ISeekable)

Reimplemented in Conduit, and SocketConduit.

protected void closure  )  [inherited]
 

Subclasses must implement closure mechanics. This is invoked when the number of close() invocations match that of aquire() -- the latter is typically called immediately following the successful construction of an IResource implementation; one should expect close to be required at least once.

Reimplemented in Conduit, FileConduit, Resource, and Socket.

Object getLock  )  [inherited]
 

Return the lock used by this resource

Reimplemented in Resource.

void setLock Object  lock  )  [inherited]
 

Set an alternate lock. Typically one would use this to synchronize multiple different Resources via a common object.

Reimplemented in Resource.

void acquire  )  [inherited]
 

hold a reference to this resource. The caller is now responsible for invoking close() upon this resource;

Reimplemented in Resource.

bool acquireIfOpen  )  [inherited]
 

If this resource is still open, acquire it and return true. This is a threadsafe test-and-set mechanism that fails only if the resource is already closed, or was never opened.

Note that you are responsible for invoking close() whenever this method returns true.

Reimplemented in Resource.

void close  )  [inherited]
 

release a reference to this resource

Reimplemented in Resource.

Referenced by HttpClient::close(), ConnectionPool::PoolConnection::close(), HttpBridge::cross(), ClusterThread::run(), and testClient().

int reader void[]  dst  )  [inherited]
 

conduit-specific reader

Reimplemented in Conduit, ConduitSource, and SocketConduit.

void bind IConduitSource  next  )  [inherited]
 

Reimplemented in Conduit, ConduitSource, and SocketConduit.

Referenced by SocketConduit::attach(), and Conduit::attach().

void unbind  )  [inherited]
 

Reimplemented in Conduit, ConduitSource, and SocketConduit.

Referenced by SocketConduit::VersionUseFreeList::closure(), Conduit::closure(), and ConduitSource::unbind().

int writer void[]  src  )  [inherited]
 

conduit-specific writer

Reimplemented in Conduit, ConduitSink, and SocketConduit.

void bind IConduitSink  next  )  [inherited]
 

Reimplemented in Conduit, ConduitSink, and SocketConduit.

Referenced by SocketConduit::attach(), and Conduit::attach().

void unbind  )  [inherited]
 

Reimplemented in Conduit, ConduitSink, and SocketConduit.

Referenced by SocketConduit::VersionUseFreeList::closure(), Conduit::closure(), and ConduitSink::unbind().


The documentation for this struct was generated from the following file:
Generated on Sun Nov 7 19:07:05 2004 for Mango by doxygen 1.3.6