This is Info file pm.info, produced by Makeinfo version 1.68 from the input file bigpm.texi.  File: pm.info, Node: Slay/MakerRule, Next: SlideShow, Prev: Slay/Maker, Up: Module List a class for making things with dependancies ******************************************* NAME ==== Slay::MakerRule - a class for making things with dependancies SYNOPSIS ======== use strict ; use Slay::MakerRule ; $t1 = Slay::MakerRule->new( \@target, ## Filenames made by \@actions \@dependencies, ## Files or Slay::MakerRule objects \@actions, ## Command lines or sub{} ) ; Any or all of the three parameters may be scalars if there is only one thing to pass: $t1 = Slay::MakerRule->new( $target, $dependency, $action, ) ; DESCRIPTION =========== check Builds the queue of things to make if this target or it's dependencies are out of date. exec Executes the action(s) associated with this rule. targets returns either ( target1, target2, ... ) or "target1, target2, ..." depending on context. matches Checks the target list to see if it matches the target passed in.  File: pm.info, Node: SlideShow, Next: Slinke, Prev: Slay/MakerRule, Up: Module List Perl extension remote presentation ********************************** NAME ==== SlideShow - Perl extension remote presentation SYNOPSIS ======== use SlideShow; new SlideShow (master_cgi => "http://127.0.0.1/cgi-bin/master", start_title => "My SlideShow", url_list => [qw(http://www.perl.com http://www.infobot.org)], )->run; perl -MSlideShow -e 'SlideShow->new()->run'; perl -MSlideShow -e 'SlideShow->client()->run'; DESCRIPTION =========== SlideShow is a device for giving presentations over the Web. It allows one user (the master) to control the content that appears on other user (client) browsers by using server pushes. For example, you could arrange a conference call or radio broadcast, and then tell everyone to point their browsers at a client CGI, and then give the talk with visual materials. PREREQUISITES ============= LWP::UserAgent, HTTP::Request, HTML::Parser, CGI.pm, and web server that will allow you to run CGIs. RUNNING A SLIDESHOW =================== You will need a web server that will allow you to use CGI, but it is otherwise a simple matter to run a SlideShow. First, have the session leader start a master session. This is done by creating a SlideShow object and passing it a few parameters, such as: master_cgi The URL to the master CGI program, wherever you are utting it. [Required]. view_file Where to keep the currently-showing pages. start_title The title that shows up on the master session at startup. url_list A list of URLs to use as presets to start off the session with. tmp_dir Where to keep the temporary files. default is `/tmp'. log_file Where to put the final log of all pages visited. commentary A little message that goes on the master startup page. HTML can be included verbatim. EXAMPLES ======== for the master session: use SlideShow; new SlideShow (master_cgi => "http://127.0.0.1/cgi-bin/master", start_title => "My SlideShow", view_file => "/tmp/viewfile.html", url_list => [qw(http://www.perl.com http://www.infobot.org)], )->run; for the clients/viewers: use SlideShow; SlideShow::client(view_file => "/tmp/viewfile.html"); NOTE: the push involved non-parsed headers (NPH) and many browsers require that a CGI be named with the prefix 'nph-', such as 'nph-view', to work properly. See the included examples, *slideshow-master* and *nph-slideshow-viewer*. BUGS ==== Requires someone or something to lead the session. Autonomous shows should be added. AUTHOR ====== Kevin A. Lenzo SEE ALSO ======== perl(1), *Note LWP/UserAgent: LWP/UserAgent,, *Note HTTP/Request: HTTP/Request,, *Note HTML/Parser: HTML/Parser,, *Note CGI: CGI,.  File: pm.info, Node: Slinke, Next: Smil, Prev: SlideShow, Up: Module List module to control the Slink-e product produced by Nirvis - visit Nirvis at http://www.nirvis.com ************************************************************************************************ NAME ==== Slinke - module to control the Slink-e product produced by Nirvis - visit Nirvis at http://www.nirvis.com SYNOPSIS ======== use Slinke; # Create a Slinke and read from the infrared port my $slinke = new Slinke; my $data = $slinke->requestInput(); foreach my $i ( @$data ) { print "$i\n"; } DESCRIPTION =========== Slink-e is a product that can speak to many different Sony products over the S-Link port. Also, it can receive and transmit infrared signals over 8 different transmitters/receivers. For now, the bulk of this code deals with the transmission and reception of these infrared signals. Note that this code borrows heavily from C++ code from Colby Boles. In fact, sometimes I just copied his code and comments verbatim. METHODS ======= EXPORT ------ The different port names are exported. These are the following: PORT_SL0 PORT_SL1 PORT_SL2 PORT_SL3 PORT_IR PORT_PAR PORT_SER PORT_SYS $slinke = new Slinke( [ DEVICE => $device, SERIALPORT => $serialport ] ); ------------------------------------------------------------------------- Returns a newly created `Slinke' object. `$device' is the name of the device that the Slink-e is connected to. If no device is provided, a search is made on the following devices: /dev/ttyS0 /dev/ttyS1 /dev/ttyS2 /dev/ttyS3 On windows, COM ports 1-8 are searched If you would rather provide a SerialPort object, you can do that by setting the SERIALPORT argument $slinke->requestInput(); ------------------------ This function returns any input from the S-Link ports, the IR ports or the Parallel port The returned element is a hash reference. `PORT' is always set, and it will contain the port that returned the data DATA is a reference to an array of values. TIME is set for data coming from the IR port and this lists the total amount of time that was needed to produce the IR signal `IRPORT' is set for data coming from the IR port. It tells which IR receiver (1-8) the data was received on. Note that you must have a Slink-e of version 2.0 or higher for IRPORT to be greater than 0 $slinke->requestSerialNumber() ------------------------------ This returns the 8 byte serial number of the Slink-e. $slinke->requestBaud() ---------------------- This returns the baud rate in bps of the Slink-e. $slinke->setBaud() ------------------ This sets the baud rate in bps of the Slink-e. $slinke->requestFirmwareVersion() --------------------------------- This returns the firmware version of the Slink-e $slinke->enablePort( $port ) ---------------------------- Enables reception on specified port. If port == `PORT_SYS' *all ports are not enabled*, instead each port is returned to its enabled/disabled state previous to the global disablement. $slinke->disablePort( $port ) ----------------------------- Disables reception on specified port. If port == `PORT_SYS', all ports are disabled. Disabling a port does not prevent the host from sending messages out the port, only receiving them. $slinke->requestIRSamplingPeriod() ---------------------------------- This returns the infrared sampling period of the Slink-e. Values can range from 50 microseconds to 1 millisecond. The IR sampling period determines the maximum timing resolution which can be achieved when decoding IR signals. In general, the sampling period should be at least 3 times shorter than the shortest pulse you wish to detect. Short sampling periods are necessary when acquiring timing information about new remote signals, but are not necessarily need to output known remote signals since the sampling period need only be the least common multiple of the pulse widths in the signal. The IR sampling period is also used as a timebase for parallel port output signals. $slinke->setIRSamplingPeriod( $time ) ------------------------------------- This sets the infrared sampling period of the Slink-e. Values can range from 50 microseconds to 1 millisecond in 1/5 microsecond steps. Upon success, this function will return the sampling period. On value, it will return undef. The IR sampling period determines the maximum timing resolution which can be achieved when decoding IR signals. In general, the sampling period should be at least 3 times shorter than the shortest pulse you wish to detect. Short sampling periods are necessary when acquiring timing information about new remote signals, but are not necessarily need to output known remote signals since the sampling period need only be the least common multiple of the pulse widths in the signal. The IR sampling period is also used as a timebase for parallel port output signals. $slinke->requestIRCarrier() --------------------------- This returns the IR carrier frequency of the Slink-e. $slinke->setIRCarrier( $frequency ) ----------------------------------- This sets the IR carrier frequency of the Slink-e. Note that because of the way that the frequency gets set, it will be very unlikely that you will be able to set the exact frequency that you want. However, the Slink-e should be able to handle your frequency within several hundred hertz. Upon success, the frequency that the Slink-e is using will be returned. Upon failure, undef is returned. $slinke->requestIRTimeoutPeriod() --------------------------------- This returns the IR timeout period of the Slink-e as measured in sample periods. The timeout period defines how ling the IR receiver module must be inactive for the Slink-e to consider a message to be completed. $slinke->setIRTimeoutPeriod( $sample_periods ) ---------------------------------------------- This returns the IR timeout period of the Slink-e as measured in sample periods. The timeout period defines how ling the IR receiver module must be inactive for the Slink-e to consider a message to be completed. Most IR remotes repeat commands many times for one keypress. If you want to see each command as a separate message, set the timeout period to be less than the off time between commands. If you to see the keypress as one long message with repeated commands, set the timeout period to be longer than the off time between commands. The latter mode is particularly useful for initially determining the timing information for a new remote. On success, the new value of the timeout period will be returned. On failure, undef is returned. $slinke->requestIRMinimumLength() --------------------------------- This returns the length of the shortest IR receive message in bytes which will be considered a valid message. $slinke->setIRMinimumLength( $bytes ) ------------------------------------- This set the length of the shortest IR receive message in bytes which will be considered a valid message. IR receiver modules such as the one on the Slink-e tend to be very sensitive to both optical and electrical noise, causing them to occasionally generate false pulses when there is no actual IR signal. The false pulses are generally of short duration and do not contain the large number of on/off alternations present in a true IR remote signal. By setting a minimum message length, false pulses will be ignored and not reported to the host. The minimum length can range from 0 to 15 bytes. Upon success, the new minimum message length is returned. Upon failure, undef is returned. $slinke->requestIRTransmitPorts() --------------------------------- This returns the value of the ports that the Slink-e uses for IR transmissions. The bits represent the 8 IR ports, IR0 being the LSB, IR7 the MSB. A "1" indicates the port will be used. *This command requires a firmware version of 2.0 and above* $slinke->setIRTransmitPorts( $ports ) ------------------------------------- This sets the ports that the Slink-e uses for IR transmissions. The bits represent the 8 IR ports, IR0 being the LSB, IR7 the MSB. A "1" indicates the port will be used. *This command requires a firmware version of 2.0 and above* $slinke->requestIRPolarity() ---------------------------- Reports the polarity sense of each of the IR ports. These settings will also affect the IR routing system. The bits of the response represent the 8 IR ports, IR0 being the LSB, IR7 the MSB. A "1" bit indicates that the input is active-low (when the input goes to 0 Volts), a "0" bit indicates that the input is active-high (when the input goes to 5 Volts). All ports are active-low by default so that they will work correctly with the IR receiver modules. If you have some other low-speed serial device which is active-high (e.g. a Control-S input) that you would like to connect, you will want to change the polarity on that port. Be careful with this option - if you set the wrong polarity for a port, the Slink-e will be locked into a constant receive state and will become unresponsive. *This command requires a firmware version of 2.0 and above* $slinke->setIRPolarity( $ports ) -------------------------------- Sets the polarity sense of each of the IR ports. These settings will also affect the IR routing system. The bits of $ports represent the 8 IR ports, IR0 being the LSB, IR7 the MSB. A "1" bit indicates that the input is active-low (when the input goes to 0 Volts), a "0" bit indicates that the input is active-high (when the input goes to 5 Volts). All ports are active-low by default so that they will work correctly with the IR receiver modules. If you have some other low-speed serial device which is active-high (e.g. a Control-S input) that you would like to connect, you will want to change the polarity on that port. Be careful with this option - if you set the wrong polarity for a port, the Slink-e will be locked into a constant receive state and will become unresponsive. *This command requires a firmware version of 2.0 and above* $slinke->requestIRReceivePorts() -------------------------------- This returns the value of the ports that the Slink-e uses for IR reception. The bits represent the 8 IR ports, IR0 being the LSB, IR7 the MSB. A "1" indicates the port will be used. *This command requires a firmware version of 2.0 and above* $slinke->setIRReceivePorts( $ports ) ------------------------------------ This sets the ports that the Slink-e uses for IR reception. The bits represent the 8 IR ports, IR0 being the LSB, IR7 the MSB. A "1" indicates the port will be used. *This command requires a firmware version of 2.0 and above* Upon success, this returns the ports that the Slink-e is using for IR reception. Upon failure, undef is returned. $slinke->requestIRRoutingTable() -------------------------------- This response describes the IR routing table. The routelist byte for each IRRX port specifies which IRTX ports the received signal will be echoed to. The format for this byte is the same as the Set IR transmit ports command. The carrier byte specifes the carrier frequency to be used in the routed signals from a given IRRX port. This byte is equivalent to the CC byte in the Set IR carrier command. To reduce data storage requirements, no prescaler value can be specified and the prescaler is defaulted to 0 instead. This means that 15.7khz is the lowest available carrier frequency for IR routing. *This command requires a firmware version of 2.0 and above* $slinke->setIRRoutingTable( @data ) ----------------------------------- This command sets up the IR routing table. The routelist byte for each IRRX port specifies which IRTX ports the received signal will be echoed to. The format for this byte is the same as the Set IR transmit ports command. The carrier byte specifes the carrier frequency to be used in the routed signals from a given IRRX port. This byte is equivalent to the CC byte in the Set IR carrier command. To reduce data storage requirements, no prescaler value can be specified and the prescaler is defaulted to 0 instead. This means that 15.7khz is the lowest available carrier frequency for IR routing. *This command requires a firmware version of 2.0 and above* $slinke->requestHandshaking() ----------------------------- Reports the input and output handshaking mode for the Parallel Port. As a binary number, the output looks as follows: `[0 0 0 0 0 0 in out]' Only the bits in and out are used. in = 0 : Disable Input Handshaking (default at startup). Disable the use of DISTB/DIO7 as a handshaking pin, in turn freeing it for general I/O use. When input handshaking is enabled, rising edges on the DISTB input cause the Parallel Port data to be sampled and sent to the host in the form of a port receive message. When disabled, sampling of the Parallel Port only occurs when a sample port message is issued. in = 1 : Enable Input Handshaking Enables the use of DISTB/DIO7 as a handshaking pin, in turn removing it from general I/O use. When input handshaking is enabled, rising edges on the DISTB input cause the Parallel Port data to be sampled and sent to the host in the form of a port receive message. When disabled, sampling of the Parallel Port only occurs when a sample port message is issued. out= 0 : Disable Output Handshaking (default at startup). Disable the use of DOSTB/DIO6 as a handshaking pin, in turn freeing it for general I/O use. When output handshaking is enabled, each data byte sent out the Parallel Port using the port send command will be accompanied by a positive DOSTB pulse lasting one IR sampling period. out = 1 : Enable Output Handshaking Enable the use of DOSTB/DIO6 as a handshaking pin, in turn removing it from general I/O use. When output handshaking is enabled, each data byte sent out the Parallel Port using the port send command will be accompanied by a positive DOSTB pulse lasting one IR sampling period. $slinke->setHandshaking( $handshaking ) --------------------------------------- Sets the input and output handshaking mode for the Parallel Port. As a binary number, `$handshaking' looks as follows: `[0 0 0 0 0 0 in out]' Only the bits in and out are used. in = 0 : Disable Input Handshaking (default at startup). Disable the use of DISTB/DIO7 as a handshaking pin, in turn freeing it for general I/O use. When input handshaking is enabled, rising edges on the DISTB input cause the Parallel Port data to be sampled and sent to the host in the form of a port receive message. When disabled, sampling of the Parallel Port only occurs when a sample port message is issued. in = 1 : Enable Input Handshaking Enables the use of DISTB/DIO7 as a handshaking pin, in turn removing it from general I/O use. When input handshaking is enabled, rising edges on the DISTB input cause the Parallel Port data to be sampled and sent to the host in the form of a port receive message. When disabled, sampling of the Parallel Port only occurs when a sample port message is issued. out= 0 : Disable Output Handshaking (default at startup). Disable the use of DOSTB/DIO6 as a handshaking pin, in turn freeing it for general I/O use. When output handshaking is enabled, each data byte sent out the Parallel Port using the port send command will be accompanied by a positive DOSTB pulse lasting one IR sampling period. out = 1 : Enable Output Handshaking Enable the use of DOSTB/DIO6 as a handshaking pin, in turn removing it from general I/O use. When output handshaking is enabled, each data byte sent out the Parallel Port using the port send command will be accompanied by a positive DOSTB pulse lasting one IR sampling period. Upon success, the new handshaking setting is returned Upon failure, undef is returned. $slinke->requestDirection() --------------------------- Reports which parallel port lines are inputs or outputs. The bits d7:d0 in the output correspond 1 to 1 with the Parallel Port I/O lines DIO7:DIO0. Setting a direction bit to 1 assigns the corresponding DIO line as an input, while setting it to 0 make it an output. At startup, all DIO lines are configured as inputs. The use of handshaking on lines DISTB/DIO7 and DOSTB/DIO6 overrides the direction configuration for these lines while enabled. $slinke->setDirection( $direction ) ----------------------------------- Configures the parallel port lines as inputs or outputs. The bits d7:d0 in the direction byte correspond 1 to 1 with the Parallel Port I/O lines DIO7:DIO0. Setting a direction bit to 1 assigns the corresponding DIO line as an input, while setting it to 0 make it an output. At startup, all DIO lines are configured as inputs. The use of handshaking on lines DISTB/DIO7 and DOSTB/DIO6 overrides the direction configuration for these lines while enabled. Slink-e will return a configuration direction equals response to verify your command. $slinke->sampleParPort() ------------------------ Causes the Slink-e to sample the Parallel Port inputs just as if it had seen a rising edge on DISTB when input handshaking is enabled. This command works whether input handshaking is enabled or not. The Slink-e will respond with a port receive message containing the Parallel Port data. Note that this function does not actually return the parallel port data. To get that, you must call the `requestInput' function. $slinke->sendIR( DATA => $data [, IRPORT => $ports ] ) ------------------------------------------------------ This function allows you to send IR signals. The DATA element should be an array reference of run length coded signals. If you wish to send the IR on specific ports, set the `IRPORT' element. This function will automatically mute the IR Receivers while data is being sent so that the receiver will not capture what the transmitter is sending. $slinke->sendData( DATA => $data, PORT => $port ) ------------------------------------------------- This allows data to be sent over a S-Link port or the parallel port. The `PORT' element must be set to either `PORT_SL0', `PORT_SL1', `PORT_SL2' or `PORT_PAR'. The data element should be an array reference of the data to be sent. $slinke->reset() ---------------- Warm-boots the Slink-e, resetting all defaults including the baud rate. In version 2.0 or greater, these defaults are loaded from an EEPROM which is user programmable. $slinke->loadDefaults() ----------------------- Causes the Slink-e to load all of the current user settings from EEPROM memory so that they are returned to their default values, Be wary of the fact that the baud rate stored in EEPROM could be different than the current baud rate. In this case communications will be lost until the host detects the new baud rate. If successful, the Slink-e will send a defaults loaded response. *This command requires a firmware version of 2.0 and above* $slinke->saveDefaults() ----------------------- Causes the Slink-e to save all of the current user settings to EEPROM memory so that they will become the defaults the next time the Slink-e is reset or powered-up. If successful, the Slink-e will send a defaults saved response. *This command requires a firmware version of 2.0 and above* decodeIR( @data ) ----------------- This will take the data returned by requestInput and attempt to convert it to a bit string. This function returns a hash reference. Elements of the hash reference HEAD => The wakeup call for the device. These are typically the first two bytes in the data array. This is an array reference. CODE => This is a bit string indicating the command that was sent. For Sony devices, a "P" is thrown in when a pause in the data array is detected. TAIL => The bytes that indicate the end of the data string. These are typically the last five bytes of the data array. This is an array reference. ENCODING => This is an array reference of two array references that describes how zeroes and ones are encoded. TODO ==== Add bin mode for S-Link ports AUTHOR ====== Brian Paulsen Copyright 2000, Brian Paulsen. All rights reserved. This library is free software; you can redistribute it and/or modify it under the same terms as Perl itself. Bug reports and comments to Brian@ThePaulsens.com. For further information about the Slink-e, visit http://www.nirvis.com  File: pm.info, Node: Smil, Next: Socket, Prev: Slinke, Up: Module List Perl extension for dynamic generation of SMIL files. **************************************************** NAME ==== Smil.pm - Perl extension for dynamic generation of SMIL files. SYNOPSIS ======== use Smil; (read on, good knight...) DESCRIPTION =========== This module provides an object oriented interface to generation of SMIL (Synchronized Multimedia Integration Language) files. Creating a simple SMIL file is as simple as this script: use Smil; $s = new Smil; print $s->header; # Remember MIME header if running as CGI $s->addMedia( "src" => "rtsp://videoserver.com/video.rm" ); print $s->getAsString(); This will create the following SMIL file with the correct header, perfect for a CGI script coming off a web server: Content-type: application/smil Your first SMIL file! Actually, this doesn't do much, but SMIL beginners can't be choosers, right? As a new feature as of 0.70, you can now use Quicktime extensions. Peruse the qt.pl file in the installation directory for a sampling of the methods you can call for Quicktime extensions added to the element. Otherwise, add the attributes and their values directly into SMIL when you call addMedia. Smil.pm will allow any namespace attributes to pass through to the media element. When you do add one of these attributes, or call something like setQtAutoplay(), Smil.pm automatically adds the xmlns:qt attribute with the proper unique identifier to the element. So, if you decide midway through creation of a SMIL file that you want Quicktime extensions, call the proper method and Smil.pm will add the proper code to add these extensions to your SMIL file. You can do more advanced things by adding regions to your SMIL files, and playing media inside those regions. $s = new Smil( "height" => 300, "width" => 300 ); $region_name = "first_region"; $s->addRegion( "name" => $region_name, "top" => 20, "left" => 35, "height" => 100, "width" => 100 ); $s->addMedia( "src" => "rtsp://videoserver.com/video.rm", "region" => $region_name ); print $s->getAsString; This code results in the following output: (Well, sort of, I had to reformat it so that it didn't stretch past the end of the line, but functionally exactly the same) All of this would be somewhat trivial if this module didn't expose the main differentiator between SMIL and HTML - the timeline! With SMIL you can synchronize and schedule your media over a timeline, all without nasty proprietary scripting solutions. This idea is built into SMIL and exposed in this module. $s = new Smil( "height" => 300, "width" => 300 ); $region1 = "first_region"; $region2 = "second_region"; $s->addRegion( "name" => $region1, "top" => 20, "left" => 35, "height" => 100, "width" => 100 ); $s->addRegion( "name" => $region2, "top" => 60, "left" => 55, "height" => 120, "width" => 120 ); $s->startSequence(); $s->addMedia( "src" => "rtsp://videoserver.com/video1.rm", "region" => $region1 ); $s->addMedia( "src" => "rtsp://videoserver.com/video2.rm", "region" => $region2 ); $s->endSequence(); print $s->getAsString; Results in this (again formatted to fit your screen...) You can schedule media in two ways, by calling startSequence coupled with endSequence or startParallel with endParallel, as you saw above, or you can specify begin and end times within the media directly for an absolute timeline. $s = new Smil( "height" => 300, "width" => 300 ); $region1 = "first_region"; $region2 = "second_region"; $s->addRegion( "name" => $region1, "top" => 20, "left" => 35, "height" => 100, "width" => 100 ); $s->addRegion( "name" => $region2, "top" => 60, "left" => 55, "height" => 120, "width" => 120 ); $s->startParallel(); $s->addMedia( "src" => "rtsp://videoserver.com/video1.rm", "region" => $region1 ); $s->addMedia( "src" => "rtsp://videoserver.com/video1.rm", "region" => $region2, "begin" => "5s" ); $s->endParallel(); print $s->getAsString(); Producing this: Notice the "begin" parameter, this tells the media its absolute begin time. The above code will start the second clip 5 seconds after the first even though they are playing in parallel You can add your own code using the addCode method $s->addCode( "" ); You can add comments by using the addComment method $s->addComment( "A comment is here" ); PerlySMIL will add the necessary comment code around the comment, so you get back You as the author are responsible for formatting, so don't expect that your arbitrary code will be indented like the rest of the SMIL. Like HTML, SMIL applications can have hyperlinks. There are two types in SMIL: normal hrefs, and anchors. An href covers the entire media item, whereas an anchor covers a rectangular portion of the media item. To create an href, add the "href" parameter when you add the media to the SMIL object. $s->addMedia( "src" => "rtsp://videosource.com/video.rm", "show" => "new", "href" => "http://www.destinationlink.com/link.html" ); Adding anchors is more complex, but much more versatile. You can do everything with anchors that you can do with hrefs, but with anchors you add the capability to change the hyperlinks over time and specify only portions of the media item for linking. To create an anchor you need to pass, brace yourself, a reference to an array of hash references. Mimic the code below if you don't want to know what that means. The format is like this: [ { hash_values }, { hash_values } ] where hash_values are key-value pairs like "bob" => "sally" (Perl gurus know that "=>" is a synonym for comma...) Here's a code example to get you started. $smil->addMedia( 'src' => "video.rm", 'anchors' => [ { 'href' => "http://websrv.com/index.html, 'coords' => '0,0,110,50', 'show' => 'new', 'begin' => 3 } , { 'href' => "another.smil", 'coords' => '125,208,185,245', 'begin' => 9 } ] ); Notice several things about the above example. One, with an anchor, we can specify where we want the hyperlink to persist over the media item. This is done using a coordinate system with two points, the top, left corner, and the bottom, right corner. So, if we wanted to remove the href tag completely, we could just specify the entire canvas of the media item in the coordinate parameter and we would have the same thing as a href. Also, in the above example, we started some hyperlinks at different times. The first one begins a 3 seconds, and the second begins at 9 seconds. We could have also specified end times using the "end" parameter/attribute. Finally, since a SMIL is not HTML we have to have a mechanism for dealing with links to HTML files (or other media for that matter) and media that can play back within our SMIL player. So, if we want to send the result of clicking on a link to a web browser, we need to use the "show" parameter and give it a value of "new". If we want our SMIL player to handle the hyperlink itself (as would be the case for the second example since it is another smil file), we can either leave the "show" parameter out and let it default to the SMIL player, or explicitly add "show" => "replace" to replace the current SMIL file with the new link. As a new feature of 0.7, you can now inline your media files directly within a SMIL file. When you add media to smil using the addMedia method call, specify -inline => 1 and the module will attempt to download or read from local disk any files which are added using this attribute. Check out the inline.pl file inside the installation directory, and also the slurp.pl script which will slurp in simple SMIL files and inline all code if you give it the proper parameter. AUTHOR ====== Chris Dawson (cdawson@webiphany.com) http://www.webiphany.com/perlysmil/ SEE ALSO ======== perl(1). perldoc CGI  File: pm.info, Node: Socket, Next: Socket6, Prev: Smil, Up: Module List load the C socket.h defines and structure manipulators ****************************************************** NAME ==== Socket, sockaddr_in, sockaddr_un, inet_aton, inet_ntoa - load the C socket.h defines and structure manipulators SYNOPSIS ======== use Socket; $proto = getprotobyname('udp'); socket(Socket_Handle, PF_INET, SOCK_DGRAM, $proto); $iaddr = gethostbyname('hishost.com'); $port = getservbyname('time', 'udp'); $sin = sockaddr_in($port, $iaddr); send(Socket_Handle, 0, 0, $sin); $proto = getprotobyname('tcp'); socket(Socket_Handle, PF_INET, SOCK_STREAM, $proto); $port = getservbyname('smtp', 'tcp'); $sin = sockaddr_in($port,inet_aton("127.1")); $sin = sockaddr_in(7,inet_aton("localhost")); $sin = sockaddr_in(7,INADDR_LOOPBACK); connect(Socket_Handle,$sin); ($port, $iaddr) = sockaddr_in(getpeername(Socket_Handle)); $peer_host = gethostbyaddr($iaddr, AF_INET); $peer_addr = inet_ntoa($iaddr); $proto = getprotobyname('tcp'); socket(Socket_Handle, PF_UNIX, SOCK_STREAM, $proto); unlink('/tmp/usock'); $sun = sockaddr_un('/tmp/usock'); connect(Socket_Handle,$sun); DESCRIPTION =========== This module is just a translation of the C `socket.h' file. Unlike the old mechanism of requiring a translated `socket.ph' file, this uses the h2xs program (see the Perl source distribution) and your native C compiler. This means that it has a far more likely chance of getting the numbers right. This includes all of the commonly used pound-defines like AF_INET, SOCK_STREAM, etc. Also, some common socket "newline" constants are provided: the constants `CR', `LF', and `CRLF', as well as `$CR', `$LF', and `$CRLF', which map to `\015', `\012', and `\015\012'. If you do not want to use the literal characters in your programs, then use the constants provided here. They are not exported by default, but can be imported individually, and with the `:crlf' export tag: use Socket qw(:DEFAULT :crlf); In addition, some structure manipulation functions are available: inet_aton HOSTNAME Takes a string giving the name of a host, and translates that to the 4-byte string (structure). Takes arguments of both the 'rtfm.mit.edu' type and '18.181.0.24'. If the host name cannot be resolved, returns undef. For multi-homed hosts (hosts with more than one address), the first address found is returned. inet_ntoa IP_ADDRESS Takes a four byte ip address (as returned by inet_aton()) and translates it into a string of the form 'd.d.d.d' where the 'd's are numbers less than 256 (the normal readable four dotted number notation for internet addresses). INADDR_ANY Note: does not return a number, but a packed string. Returns the 4-byte wildcard ip address which specifies any of the hosts ip addresses. (A particular machine can have more than one ip address, each address corresponding to a particular network interface. This wildcard address allows you to bind to all of them simultaneously.) Normally equivalent to inet_aton('0.0.0.0'). INADDR_BROADCAST Note: does not return a number, but a packed string. Returns the 4-byte 'this-lan' ip broadcast address. This can be useful for some protocols to solicit information from all servers on the same LAN cable. Normally equivalent to inet_aton('255.255.255.255'). INADDR_LOOPBACK Note - does not return a number. Returns the 4-byte loopback address. Normally equivalent to inet_aton('localhost'). INADDR_NONE Note - does not return a number. Returns the 4-byte 'invalid' ip address. Normally equivalent to inet_aton('255.255.255.255'). sockaddr_in PORT, ADDRESS sockaddr_in SOCKADDR_IN In an array context, unpacks its SOCKADDR_IN argument and returns an array consisting of (PORT, ADDRESS). In a scalar context, packs its (PORT, ADDRESS) arguments as a SOCKADDR_IN and returns it. If this is confusing, use pack_sockaddr_in() and unpack_sockaddr_in() explicitly. pack_sockaddr_in PORT, IP_ADDRESS Takes two arguments, a port number and a 4 byte IP_ADDRESS (as returned by inet_aton()). Returns the sockaddr_in structure with those arguments packed in with AF_INET filled in. For internet domain sockets, this structure is normally what you need for the arguments in bind(), connect(), and send(), and is also returned by getpeername(), getsockname() and recv(). unpack_sockaddr_in SOCKADDR_IN Takes a sockaddr_in structure (as returned by pack_sockaddr_in()) and returns an array of two elements: the port and the 4-byte ip-address. Will croak if the structure does not have AF_INET in the right place. sockaddr_un PATHNAME sockaddr_un SOCKADDR_UN In an array context, unpacks its SOCKADDR_UN argument and returns an array consisting of (PATHNAME). In a scalar context, packs its PATHNAME arguments as a SOCKADDR_UN and returns it. If this is confusing, use pack_sockaddr_un() and unpack_sockaddr_un() explicitly. These are only supported if your system has <`sys/un.h'>. pack_sockaddr_un PATH Takes one argument, a pathname. Returns the sockaddr_un structure with that path packed in with AF_UNIX filled in. For unix domain sockets, this structure is normally what you need for the arguments in bind(), connect(), and send(), and is also returned by getpeername(), getsockname() and recv(). unpack_sockaddr_un SOCKADDR_UN Takes a sockaddr_un structure (as returned by pack_sockaddr_un()) and returns the pathname. Will croak if the structure does not have AF_UNIX in the right place.  File: pm.info, Node: Socket6, Next: Socket/PassAccessRights, Prev: Socket, Up: Module List load IPv6 related part of the C socket.h defines and structure manipulators *************************************************************************** NAME ==== Socket6, sockaddr_in6, inet_pton, inet_ntop - load IPv6 related part of the C socket.h defines and structure manipulators SYNOPSIS ======== use Socket; use Socket6; @res = getaddrinfo('hishost.com', 'daytime', AF_UNSPEC, SOCK_STREAM); $family = -1; while (scalar(@res) >= 5) { ($family, $socktype, $proto, $saddr, $canonname, @res) = @res; ($host, $port) = getnameinfo($saddr, NI_NUMERICHOST | NI_NUMERICSERV); print STDERR "Trying to connect to $host port port $port...\n"; socket(Socket_Handle, $family, $socktype, $proto) || next; connect(Socket_Handle, $saddr) && last; close(Socket_Handle); $family = -1; } if ($family != -1) { print STDERR "connected to $host port port $port\n"; } else { die "connect attempt failed\n"; } DESCRIPTION =========== This module supports getaddrinfo() and getnameinfo() to intend to enable protocol independent programing. If your environment supports IPv6, IPv6 related defines such as AF_INET6 are included. If you use Socket6 module, be sure to specify "use Socket" as well as "use Socket6". Functions supplied are: inet_pton AF HOST inet_ntop AF ADDR pack_sockaddr_in6 PORT ADDR pack_sockaddr_in6_all PORT FLOWINFO ADDR SCOPEID unpack_sockaddr_in6 NAME unpack_sockaddr_in6_all NAME gethostbyname2 HOSTNAME, SERVNAME getaddrinfo HOSTNAME, SERVNAME, FAMILY, SOCKTYPE, PROTOCOL, FLAGS Arguments from FAMILY to FLAGS are optional. getnameinfo NAME, FLAGS FLAGS argument is optional.  File: pm.info, Node: Socket/PassAccessRights, Next: Softref, Prev: Socket6, Up: Module List SYNOPSIS ======== use Socket::PassAccessRights; Socket::PassAccessRights::sendfd(fileno(SOCKET), fileno(SEND_ME)) or die; $fd = Socket::PassAccessRights::recvfd(fileno(SOCKET)) or die; open FD, ">&=$fd" or die "$!"; # convert int fd to file handle DESCRIPTION =========== Implements passing access rights (i.e. file descritors) over Unix domain sockets. Only one fd can be passed at one time and no other data can be sent in the same operation (operation itself involves sending exactly one byte of data to solve EOF detection anomaly). See test.pl and examples directory for usage examples. PLATFORMS ========= This code has only been tested on * Linux-2.0.38 with glibc-2.0.7 (libc.so.6) and libc.so.5 (BSD4.4 style) * Linux-2.2.14 with glibc-2.0.7 (libc.so.6) (BSD4.4 style) * Solaris-2.6 using gcc (BSD4.3 style) Specifically, the code from [Stevens] did not work out of the box. I had to rename msg.msg_accrights* to msg.control* and send at least one byte. General impression from net is that file descripto passing code seems to be buggy - not just in Linux, but on FreeBSD, too. AUTHOR AND COPYRIGHT ==================== Sampo Kellomaki Copyright (c) 2000 by Sampo Kellomaki , All Rights Reserved. This module may be copied under the same terms as perl itself. SEE ALSO ======== Home page: http://www.bacus.pt/Net_SSLeay/modules.html perl(1) recvmsg(2) sendmsg(2) Richard Stevens: Unix Network Programming, Prentice Hall, 1990; chapter 6.10. /usr/include/socketbits.h /usr/include/sys/socket.h  File: pm.info, Node: Softref, Next: Solaris/Contents, Prev: Socket/PassAccessRights, Up: Module List Perl extension for blah blah blah ********************************* NAME ==== Softref - Perl extension for blah blah blah SYNOPSIS ======== use Softref; blah blah blah DESCRIPTION =========== Stub documentation for Softref was created by h2xs. It looks like the author of the extension was negligent enough to leave the stub unedited. Blah blah blah. Exported functions ================== void sv_rvsoft(SV*); AUTHOR ====== A. U. Thor, a.u.thor@a.galaxy.far.far.away SEE ALSO ======== perl(1).  File: pm.info, Node: Solaris/Contents, Next: Solaris/InstallDB, Prev: Softref, Up: Module List Read /var/sadm/install/contents file ************************************ NAME ==== Solaris::Contents - Read /var/sadm/install/contents file SYNOPSIS ======== $c=Solaris::Contents::new(); DESCRIPTION =========== Solaris::Contents is an object oriented interface into the /var/sadm/install/contents file which Solaris uses to keep track of all the files installed on a system, and their corresponding packages. CONSTRUCTOR METHOD ================== $c=Solaris::Contents::new(); No arguements are required. By default, the object always believes the contents file is /var/sadm/install/contents. The ability to change this could change with a future release. OBJECT METHODS ============== entries() Returns an array of every file record in the contents file. Very long. entriesForPkg() Returns an array of every file record for a specified package. entry($file) Returns a hash table of every element for a specified file. ftype($file) class($file) major($file) minor($file) mode($file) user($file) group($file) size($file) cksum($file) modified($file) pkgs($file) Each of the above methods returns the specific data for a specified file entry from the contents file. Not all entries will have data specific to every method. Check the Solaris prototype man page for more information. The pkgs() method returns an array of packages related to that specific file. NOTES ===== The initialization time of Contents objects could take a few seconds depending on the size of the contents file. I may add more methods to this class later on. It would be kind of neat to do more with the link entries. AUTHOR ====== Chris Josephes, chrisj@onvoy.com  File: pm.info, Node: Solaris/InstallDB, Next: Solaris/Package, Prev: Solaris/Contents, Up: Module List Manages Solaris package information *********************************** NAME ==== Solaris::InstallDB - Manages Solaris package information SYNOPSIS ======== use Solaris::InstallDB $instdb=Solaris::InstallDB::new(-directory => $dir, -loadContents); DESCRIPTION =========== The Solaris::InstallDB class manages a directory of Solaris packages. It searches for all of the packages in a directory, and then records them in a hash table by name and architecture. It is also capable of spawning a Solaris::Contents object. With this class, you can get a list of all packages available, and all architectures it supports. It can also report some basic system about the hardware it is running on. CONSTRUCTOR METHOD ================== $instdb=Solaris::InstallDB::new(-directory => $dir, -loadContents); The new method creates a Solaris::InstallDB object. By default, it will search for objects in the /var/sadm/pkg directory, but you can change that by using the -directory parameter. If you want to create a Solaris::Contents object automatically, add the -loadContents flag. OBJECT METHODS ============== release() Returns the operating system release number in uname format. For example, if you were running a script on a Solaris 7 system, it would return 5.7. releaseAlias() Returns the commercial name of the operating system. For example, if you were running a script on an Intel system running Solaris 7, it would return 7_x86. isa() Returns the Instruction Set Architecture of the hardware. processor() Returns the processor type. hardwareClass() Returns the hardware class. arch() Returns a combination of the ISA and hardware class. packages() Returns a list of the packages found in the specified directory arches($pkg) Returns a list of architectures supported by a given package. contents() Returns the Solaris::Contents object that was created when the object was initialized. package(-name => $pkg, -arch => $arch, -debug) Returns a Solaris::Package object. If -arch isn't specified, the object will search the database for a suitable match based on the system the script is running on. If -debug is specified and the method fails to return a package object, an error message to STDOUT will explain why the method failed. pkgFile(-name => $name, -arch => $arch) Returns the filename of a particular package for the specified architecture directory() Returns the directory the object is looking for packages in NOTES ===== This object only works on packages in the directory format, not the data stream format. The code may seem a bit complex, but it's due to the fact that there are different package directories for the same package, but with different architectures. Since I have a lot of code that gives hardware information, I may work on the idea of a Solaris::Hardware package during a later code revision. AUTHOR ====== Chris Josephes, chrisj@onvoy.com