Re: Bug #676: nntp module based on imap module. (fwd)

Hi.. > I agree to use a single module for imap and nntp. I will work on the > threaded sort and let you know how it goes. My problem at the moment is the > desciding how to format the return data. I know i've seen a threaded sort already in the imap library (i believe it's undocumented) i'll look for it tomorrow.. > > I am not sure whether to sort a set of headers provided in an arrya to the > routine or to provide a structure containing all the headers in a threaded > structure. The resultant structure I use at the moment in php script is an > array of objects where one of the objects attributes is an array of objects. > > I have a feeling that such a comeplex structure would be unusable for the > run of the mill script writers and would require some support functions. This > leads me to the idea of defining a php tree strucure with routines like the > array structure that perform the data insertion and traversing operations. > A tree class could look something like > class tree { > var (object) this_data; # data for this location. > var (object) subtree[]; # array of tree objects . > var (object) leftbranch; # left and right brach poiters for creating a > binary tree. > var (object) rightbranch; # could be done by using subtree[0] for left > and subtree[1] for right. > } > > A problem I face with the threaded sort is that the messages that define the > whole depth may not be within the range of the headers supplied or no longer > available from the server. This means that a tree that defines the whole > threaded structure may contain entries for message that either should not or > cannot be retrieved. The message number header attribute could be used with > invalid values to indicate that a location is a placeholder. > Ummm...wow! highly complex!! My first question would be to figure out how/why people would need this (complex) information for a web application... Given the fact that this is all stateless, Could a solution be as simple as the thread function simply returning an array or message numbers, essentially in "thread sorted" order? When you'd display the list of messages, you'd normally be having a simple link to that article's number anyway, so any real-time manipulation of threads may be unecessary, and actually improbable. So maybe a better approach might be a set of functions to return different thread parts, something like thread_sort - returns an array of message numbers in thread order. thread_parent - returns the message number of the parent thread thread_refs - returns the number of references to the given thread Thoughts, Comments? Mark -- PHP Development Mailing List http://www.php.net/ To unsubscribe send an empty message to php-dev-unsubscribe@lists.php.net For help: php-dev-help@lists.php.net