Stream Events

Journal started Apr 15, 2006


In my study of event based programming I've run into some trouble with streaming events. Normal events have a finite length, so they can be packaged up in a memory object and sent to their handler piece-wise. But some events (like for instance ReceiveVideoStream) may involve a considerable transfer of data. Even allocating that stuff as an object in virtual memory is a formidable task, and it's better to deal with the data as it comes in, instead of waiting for the end of the event.

To do so I believe takes three handlers as a minimum. Event based XML parsers attempt to accomplish it with two, but they still have the problem of dealing with the stuff in between their tags. So to write a handler for example ReceiveVideoStream, one might write a mixin like this:

class RVS(ProtocolThingy.handler):\
	tag = "VideoStream"
	def start_event:\
		prepare_video_screen_etc()\
	def during_event(data):\
		stream_to_screen(data)\
	def end_event:\
		close_video_screen_cya_buhbye()

Whereas a standard event handler would not define an during_event function, and um... maybe... the base class's during_event function would be like "cache the data into a buffer until the end of event signal is seen." Meh, it's not that simple though, because I'm also thinking like this:

class ReceiveVideoTitle(ProtocolThingy.handler):\
	tag = "VideoTitle"\
	def process_event(event):\
		print "The Title of the Video is: %s" % event.data\

How to resolve the differences between the start/during/end paradigm that allows streaming, and the process paradigm, which delivers the event as a single whole blob? Inherit from different handler type classes? Are they on different event layers? What kind of framework could both of these function in seamlessly, and how would it work? And what's with the XML way of doing it, with no during handler?

class HandleXMLParagraph(Protocblah.handler):\
	tag = "p"\
	context = ContextHackThingyThatShouldBeInTheBaseClass()\
	def start_tag(attr):\
		context.push_paragraph()\
		do_stuff_for_starting_paragraph()\
		do_stuff_for_changing_meaning_of_inner_tags()\
	def end_tag(attr)\
		context.pop_paragraph()\
		manually_cludgily_restore_old_meanings()\
		do_stuff_for_ending_paragraph()

That's how I usually end up handling XML. Isn't there a better way than to force me to manually deal with the contexts inherent to XML?


Comment
Index
Previous (Vacation Summary)
Next (Incompatibility is Profitable)

(cc) some rights reserved