Free shower inserts software for linux

The purpose of this project is to provide a simple, generic GUI database browsing frontend. The tool is a very simple aggregation of the Qt database classes.
The database abstraction is provided by the Qt database drivers. So far, the drivers for PostgreSQL and MySQL have been found to work well.
In principle, there is no reason why ODBC drivers for popular databases such as Oracle, DB2, Informix as well as Firebird and SAP/DB shouldnt work via the Qt ODBC3 abstraction layer.
However, some preliminary tests with these have not been promising. It may be that the only way to get some of these working is to create a native Qt database driver. This is something Ill be looking into much later.
At the moment, it is only possible to build the system on Unix and similar systems. Since Trolltech have released a version of Qt for OSX under the GPL and have announced their intention to do likewise for Win32, it should be possible to provide ports for both of these platforms. For the moment though, I just provide the source.
Main features:
- Tree browser for databases and tables
- Display of table descriptions
- Display of table contents in main window
- Execution of ad-hoc SQL queries in the query tab
- Command line history in the query tab
- Retrieval of database connection details from XML config file
- Retrieval of other configuration parameters from XML config file
- Prompting for connection password
- Addition of new connections via GUI to the running application and the config file
- Display database views with a separate icon
- Create a connection name independent of the database name
- A "Test" button when creating a new connection
- Dynamically generate a list of available drivers
- Configuration via autoconf
- Fixed bug with executing updates/inserts twice
- Refreshing of a DB connection
- Deleting of connections via the GUI
- Editting of connections via the GUI
- Check for the existence of ~/.qtsql
- Creation of skeleton config file
- Auto saving/restoring of history
- Loading of queries
- Saving of results
- Keyboard shortcuts

HTML::Widgets::Index is a Perl module for creating web indexes and menus.

This module renders the index of a document tree using the data stored in a MySQL database generated by anxova. It has a flexible set of render options that gives the webmaster many options on the menu item layout.

Table

The tree data must be in a table in a database. The fields of this table should be:

id: int identifies the entry
uri: varchar(150) link of the entry
text: varchar(150) text displayed in the screen
id_parent: int the parent of the current entry. The root is 0
ordern: int menu item position on the menu

Data

Say you have a document tree like this:

a
a1.html
a2.html

b
b1.html
b2
b21.html
b22.html
b3.html

c
c1.html

Then you must enter this in the table :

; First the directory A
INSERT INTO index_items (id,id_parent,uri,text)
VALUES (1,0,a,dir A);

; Now the docs of the a dir
INSERT INTO index_items (id,id_parent,uri,text)
VALUES (2,1,a1.html,A first);
INSERT INTO index_items (id,id_parent,uri,text)
VALUES (3,1,a2.html,A 2nd);
; Now the directory B INSERT INTO index_items (id,id_parent,uri,text) VALUES (4,0,b,dir B); INSERT INTO index_items (id,id_parent,uri,text) VALUES (5,4,b1.html,B first);

; The directory B has subdirs INSERT INTO index_items (id,id_parent,uri,text) VALUES (6,4,b2,B second section);
INSERT INTO index_items (id,id_parent,uri,text)
VALUES (7,6,b21.html,B 2 1 doc);

Notice the uri field is relative, not absolute. You dont need to specify all the path to a document. So you can move docs in the directory, then just change the parent in the table.

The items are sorted alphabetically, if you want to change the order displayed in the html, just add the field ordern when you do the insert:

INSERT INTO index_items (id,id_parent,uri,text,ordern)
VALUES (5,4,b1.html,B first,2);

INSERT INTO index_items (id,id_parent,uri,text)
VALUES (6,4,b2,B second section,1);

HooDaHek (hoo-dah-hek, as in who-the-heck?) is a collection of Asterisk AGI scripts, CGI scripts, and MySQL tables intended to implement your own in-house Caller ID database and notification services.
I wrote these scripts originally to enable my household phone system to identify who was calling, be able to modify and specify my own custom CallerID labels, and to have the phone system alert us via AOL Instant Messenger or MSN Messenger as to who was calling (or had called).
Main features:
- Caller calls into your Asterisk system via IAX, SIP, or PSTN
- Your extensions.conf context sends CLID information to the hoodahek_dbhandle AGI script.
- hoodahek_dbhandle determines if the caller has called before based on the phone number.
- If YES, it does nothing.
- If NO, it inserts a row into the hoodahek table to identify the caller on subsequent calls. The initial information used is the information supplied by the telcos CLID transmission. If configured, an email is sent notifying someone of the insertion into the system. This information can then be edited by the CGI scripts provided.
- Control returns to the dialplan.
- The dialplan passes information to the hoodahek_notify AGI script.
- hoodahek_notify looks to see if stored information about this caller is in the hoodahek table.
- If YES, hoodahek_notify uses this information to announce the caller via AIM/MSN.
- If NO, hoodahek_notify looks to see if the CLID system has passed information about the caller (name, number)
- If YES, it uses that information to announce the caller via AIM/MSN.
- If NO, it announces the caller anonymously.
- hoodahek_notify uses the information it found to write a call queue file in the queue directory for the hoodahekbot.
- Control passes back into the dialplan to do whatever comes next.
- hoodahekbot scans the queue directory every second to look for new call files. When it finds one, it opens it, scans in the lines, and deletes it. It then sends an IM to each recipient as configured.

SQL::Routine is a Perl module to specify all database tasks with SQL routines.

SYNOPSIS

This executable code example shows how to define some simple database tasks with SQL::Routine; it only shows a tiny fraction of what the module is capable of, since more advanced features are not shown for brevity.

use SQL::Routine;

eval {
# Create a model/container in which all SQL details are to be stored.
# The two boolean options being set true here permit all the subsequent code to be as concise,
# easy to read, and most SQL-string-like as possible, at the cost of being slower to execute.
my $model = SQL::Routine->new_container();
$model->auto_set_node_ids( 1 );
$model->may_match_surrogate_node_ids( 1 );

# This defines 4 scalar/column/field data types (1 number, 2 char strings, 1 enumerated value type)
# and 2 row/table data types; the former are atomic and the latter are composite.
# The former can describe individual columns of a base table (table) or viewed table (view),
# while the latter can describe an entire table or view.
# Any of these can describe a domain schema object or a stored procedures variables data type.
# See also the person and person_with_parents table+view defs further below; these data types help describe them.
$model->build_child_node_trees( [
[ scalar_data_type, { si_name => entity_id , base_type => NUM_INT , num_precision => 9, }, ],
[ scalar_data_type, { si_name => alt_id , base_type => STR_CHAR, max_chars => 20, char_enc => UTF8, }, ],
[ scalar_data_type, { si_name => person_name, base_type => STR_CHAR, max_chars => 100, char_enc => UTF8, }, ],
[ scalar_data_type, { si_name => person_sex , base_type => STR_CHAR, max_chars => 1, char_enc => UTF8, }, [
[ scalar_data_type_opt, M, ],
[ scalar_data_type_opt, F, ],
], ],
[ row_data_type, person, [
[ row_data_type_field, { si_name => person_id , scalar_data_type => entity_id , }, ],
[ row_data_type_field, { si_name => alternate_id, scalar_data_type => alt_id , }, ],
[ row_data_type_field, { si_name => name , scalar_data_type => person_name, }, ],
[ row_data_type_field, { si_name => sex , scalar_data_type => person_sex , }, ],
[ row_data_type_field, { si_name => father_id , scalar_data_type => entity_id , }, ],
[ row_data_type_field, { si_name => mother_id , scalar_data_type => entity_id , }, ],
], ],
[ row_data_type, person_with_parents, [
[ row_data_type_field, { si_name => self_id , scalar_data_type => entity_id , }, ],
[ row_data_type_field, { si_name => self_name , scalar_data_type => person_name, }, ],
[ row_data_type_field, { si_name => father_id , scalar_data_type => entity_id , }, ],
[ row_data_type_field, { si_name => father_name, scalar_data_type => person_name, }, ],
[ row_data_type_field, { si_name => mother_id , scalar_data_type => entity_id , }, ],
[ row_data_type_field, { si_name => mother_name, scalar_data_type => person_name, }, ],
], ],
] );

# This defines the blueprint of a database catalog that contains a single schema and a single virtual user which owns the schema.
my $catalog_bp = $model->build_child_node_tree( catalog, Gene Database, [
[ owner, Lord of the Root, ],
[ schema, { si_name => Gene Schema, owner => Lord of the Root, }, ],
] );
my $schema = $catalog_bp->find_child_node_by_surrogate_id( Gene Schema );

# This defines a base table (table) schema object that lives in the aforementioned database catalog.
# It contains 6 columns, including a not-null primary key (having a trivial sequence generator to give it
# default values), another not-null field, a surrogate key, and 2 self-referencing foreign keys.
# Each row represents a single person, for each storing up to 2 unique identifiers, name, sex, and the parents unique ids.
my $tb_person = $schema->build_child_node_tree( table, { si_name => person, row_data_type => person, }, [
[ table_field, { si_row_field => person_id, mandatory => 1, default_val => 1, auto_inc => 1, }, ],
[ table_field, { si_row_field => name , mandatory => 1, }, ],
[ table_index, { si_name => primary , index_type => UNIQUE, }, [
[ table_index_field, person_id, ],
], ],
[ table_index, { si_name => ak_alternate_id, index_type => UNIQUE, }, [
[ table_index_field, alternate_id, ],
], ],
[ table_index, { si_name => fk_father, index_type => FOREIGN, f_table => person, }, [
[ table_index_field, { si_field => father_id, f_field => person_id } ],
], ],
[ table_index, { si_name => fk_mother, index_type => FOREIGN, f_table => person, }, [
[ table_index_field, { si_field => mother_id, f_field => person_id } ],
], ],
] );

# This defines a viewed table (view) schema object that lives in the aforementioned database catalog.
# It left-outer-joins the person table to itself twice and returns 2 columns from each constituent, for 6 total.
# Each row gives the unique id and name each for 3 people, a given person and that persons 2 parents.
my $vw_pwp = $schema->build_child_node_tree( view, { si_name => person_with_parents,
view_type => JOINED, row_data_type => person_with_parents, }, [
( map { [ view_src, { si_name => $_, match => person, }, [
map { [ view_src_field, $_, ], } ( person_id, name, father_id, mother_id, ),
], ], } (self) ),
( map { [ view_src, { si_name => $_, match => person, }, [
map { [ view_src_field, $_, ], } ( person_id, name, ),
], ], } ( father, mother, ) ),
[ view_field, { si_row_field => self_id , src_field => [person_id,self ], }, ],
[ view_field, { si_row_field => self_name , src_field => [name ,self ], }, ],
[ view_field, { si_row_field => father_id , src_field => [person_id,father], }, ],
[ view_field, { si_row_field => father_name, src_field => [name ,father], }, ],
[ view_field, { si_row_field => mother_id , src_field => [person_id,mother], }, ],
[ view_field, { si_row_field => mother_name, src_field => [name ,mother], }, ],
[ view_join, { lhs_src => self, rhs_src => father, join_op => LEFT, }, [
[ view_join_field, { lhs_src_field => father_id, rhs_src_field => person_id } ],
], ],
[ view_join, { lhs_src => self, rhs_src => mother, join_op => LEFT, }, [
[ view_join_field, { lhs_src_field => mother_id, rhs_src_field => person_id } ],
], ],
] );

# This defines the blueprint of an application that has a single virtual connection descriptor to the above database.
my $application_bp = $model->build_child_node_tree( application, Gene App, [
[ catalog_link, { si_name => editor_link, target => $catalog_bp, }, ],
] );

# This defines another scalar data type, which is used by some routines that follow below.
my $sdt_login_auth = $model->build_child_node( scalar_data_type, { si_name => login_auth,
base_type => STR_CHAR, max_chars => 20, char_enc => UTF8, } );

# This defines an application-side routine/function that connects to the Gene Database, fetches all
# the records from the person_with_parents view, disconnects the database, and returns the fetched records.
# It takes run-time arguments for a user login name and password that are used when connecting.
my $rt_fetch_pwp = $application_bp->build_child_node_tree( routine, { si_name => fetch_pwp,
routine_type => FUNCTION, return_cont_type => RW_ARY, return_row_data_type => person_with_parents, }, [
[ routine_arg, { si_name => login_name, cont_type => SCALAR, scalar_data_type => $sdt_login_auth }, ],
[ routine_arg, { si_name => login_pass, cont_type => SCALAR, scalar_data_type => $sdt_login_auth }, ],
[ routine_var, { si_name => conn_cx, cont_type => CONN, conn_link => editor_link, }, ],
[ routine_stmt, { call_sroutine => CATALOG_OPEN, }, [
[ routine_expr, { call_sroutine_cxt => CONN_CX, cont_type => CONN, valf_p_routine_item => conn_cx, }, ],
[ routine_expr, { call_sroutine_arg => LOGIN_NAME, cont_type => SCALAR, valf_p_routine_item => login_name, }, ],
[ routine_expr, { call_sroutine_arg => LOGIN_PASS, cont_type => SCALAR, valf_p_routine_item => login_pass, }, ],
], ],
[ routine_var, { si_name => pwp_ary, cont_type => RW_ARY, row_data_type => person_with_parents, }, ],
[ routine_stmt, { call_sroutine => SELECT, }, [
[ view, { si_name => query_pwp, view_type => ALIAS, row_data_type => person_with_parents, }, [
[ view_src, { si_name => s, match => $vw_pwp, }, ],
], ],
[ routine_expr, { call_sroutine_cxt => CONN_CX, cont_type => CONN, valf_p_routine_item => conn_cx, }, ],
[ routine_expr, { call_sroutine_arg => SELECT_DEFN, cont_type => SRT_NODE, act_on => query_pwp, }, ],
[ routine_expr, { call_sroutine_arg => INTO, query_dest => pwp_ary, cont_type => RW_ARY, }, ],
], ],
[ routine_stmt, { call_sroutine => CATALOG_CLOSE, }, [
[ routine_expr, { call_sroutine_cxt => CONN_CX, cont_type => CONN, valf_p_routine_item, conn_cx, }, ],
], ],
[ routine_stmt, { call_sroutine => RETURN, }, [
[ routine_expr, { call_sroutine_arg => RETURN_VALUE, cont_type => RW_ARY, valf_p_routine_item => pwp_ary, }, ],
], ],
] );

# This defines an application-side routine/procedure that inserts a set of records, given in an argument,
# into the person table. It takes an already opened db connection handle to operate through as a
# context argument (which would represent the invocant if this routine was wrapped in an object-oriented interface).
my $rt_add_people = $application_bp->build_child_node_tree( routine, { si_name => add_people, routine_type => PROCEDURE, }, [
[ routine_context, { si_name => conn_cx, cont_type => CONN, conn_link => editor_link, }, ],
[ routine_arg, { si_name => person_ary, cont_type => RW_ARY, row_data_type => person, }, ],
[ routine_stmt, { call_sroutine => INSERT, }, [
[ view, { si_name => insert_people, view_type => INSERT, row_data_type => person, ins_p_routine_item => person_ary, }, [
[ view_src, { si_name => s, match => $tb_person, }, ],
], ],
[ routine_expr, { call_sroutine_cxt => CONN_CX, cont_type => CONN, valf_p_routine_item => conn_cx, }, ],
[ routine_expr, { call_sroutine_arg => INSERT_DEFN, cont_type => SRT_NODE, act_on => insert_people, }, ],
], ],
] );

# This defines an application-side routine/function that fetches one record
# from the person table which matches its argument.
my $rt_get_person = $application_bp->build_child_node_tree( routine, { si_name => get_person,
routine_type => FUNCTION, return_cont_type => ROW, return_row_data_type => person, }, [
[ routine_context, { si_name => conn_cx, cont_type => CONN, conn_link => editor_link, }, ],
[ routine_arg, { si_name => arg_person_id, cont_type => SCALAR, scalar_data_type => entity_id, }, ],
[ routine_var, { si_name => person_row, cont_type => ROW, row_data_type => person, }, ],
[ routine_stmt, { call_sroutine => SELECT, }, [
[ view, { si_name => query_person, view_type => JOINED, row_data_type => person, }, [
[ view_src, { si_name => s, match => $tb_person, }, [
[ view_src_field, person_id, ],
], ],
[ view_expr, { view_part => WHERE, cont_type => SCALAR, valf_call_sroutine => EQ, }, [
[ view_expr, { call_sroutine_arg => LHS, cont_type => SCALAR, valf_src_field => person_id, }, ],
[ view_expr, { call_sroutine_arg => RHS, cont_type => SCALAR, valf_p_routine_item => arg_person_id, }, ],
], ],
], ],
[ routine_expr, { call_sroutine_cxt => CONN_CX, cont_type => CONN, valf_p_routine_item => conn_cx, }, ],
[ routine_expr, { call_sroutine_arg => SELECT_DEFN, cont_type => SRT_NODE, act_on => query_person, }, ],
[ routine_expr, { call_sroutine_arg => INTO, query_dest => person_row, cont_type => RW_ARY, }, ],
], ],
[ routine_stmt, { call_sroutine => RETURN, }, [
[ routine_expr, { call_sroutine_arg => RETURN_VALUE, cont_type => ROW, valf_p_routine_item => person_row, }, ],
], ],
] );

# This defines 6 database engine descriptors and 2 database bridge descriptors that we may be using.
# These details can help external code determine such things as what string-SQL flavors should be
# generated from the model, as well as which database features can be used natively or have to be emulated.
# The si_name has no meaning to code and is for users; the other attribute values should have meaning to said external code.
$model->build_child_node_trees( [
[ data_storage_product, { si_name => SQLite v3.2 , product_code => SQLite_3_2 , is_file_based => 1, }, ],
[ data_storage_product, { si_name => MySQL v5.0 , product_code => MySQL_5_0 , is_network_svc => 1, }, ],
[ data_storage_product, { si_name => PostgreSQL v8, product_code => PostgreSQL_8, is_network_svc => 1, }, ],
[ data_storage_product, { si_name => Oracle v10g , product_code => Oracle_10_g , is_network_svc => 1, }, ],
[ data_storage_product, { si_name => Sybase , product_code => Sybase , is_network_svc => 1, }, ],
[ data_storage_product, { si_name => CSV , product_code => CSV , is_file_based => 1, }, ],
[ data_link_product, { si_name => Microsoft ODBC v3, product_code => ODBC_3, }, ],
[ data_link_product, { si_name => Oracle OCI*8, product_code => OCI_8, }, ],
[ data_link_product, { si_name => Generic Rosetta Engine, product_code => Rosetta::Engine::Generic, }, ],
] );

# This defines one concrete instance each of the database catalog and an application using it.
# This concrete database instance includes two concrete user definitions, one that can owns
# the schema and one that can only edit data. The concrete application instance includes
# a concrete connection descriptor going to this concrete database instance.
# Note that user descriptions are only stored in a SQL::Routine model when that model is being used to create
# database catalogs and/or create or modify database users; otherwise user should not be kept for security sake.
$model->build_child_node_trees( [
[ catalog_instance, { si_name => test, blueprint => $catalog_bp, product => PostgreSQL v8, }, [
[ user, { si_name => ronsealy, user_type => SCHEMA_OWNER, match_owner => Lord of the Root, password => K34dsD, }, ],
[ user, { si_name => joesmith, user_type => DATA_EDITOR, password => fdsKJ4, }, ],
], ],
[ application_instance, { si_name => test app, blueprint => $application_bp, }, [
[ catalog_link_instance, { blueprint => editor_link, product => Microsoft ODBC v3, target => test, local_dsn => keep_it, }, ],
], ],
] );

# This defines another concrete instance each of the database catalog and an application using it.
$model->build_child_node_trees( [
[ catalog_instance, { si_name => production, blueprint => $catalog_bp, product => Oracle v10g, }, [
[ user, { si_name => florence, user_type => SCHEMA_OWNER, match_owner => Lord of the Root, password => 0sfs8G, }, ],
[ user, { si_name => thainuff, user_type => DATA_EDITOR, password => 9340sd, }, ],
], ],
[ application_instance, { si_name => production app, blueprint => $application_bp, }, [
[ catalog_link_instance, { blueprint => editor_link, product => Oracle OCI*8, target => production, local_dsn => ship_it, }, ],
], ],
] );

# This defines a third concrete instance each of the database catalog and an application using it.
$model->build_child_node_trees( [
[ catalog_instance, { si_name => laptop demo, blueprint => $catalog_bp, product => SQLite v3.2, file_path => Move It, }, ],
[ application_instance, { si_name => laptop demo app, blueprint => $application_bp, }, [
[ catalog_link_instance, { blueprint => editor_link, product => Generic Rosetta Engine, target => laptop demo, }, ],
], ],
] );

# This line will run some correctness tests on the model that were not done
# when the model was being populated for execution speed efficiency.
$model->assert_deferrable_constraints();

# This line will dump the contents of the model in pretty-printed XML format.
# It can be helpful when debugging your programs that use SQL::Routine.
print $model->get_all_properties_as_xml_str( 1 );
};
$@ and print error_to_string($@);

# SQL::Routine throws object exceptions when it encounters bad input; this function
# will convert those into human readable text for display by the try/catch block.
sub error_to_string {
my ($message) = @_;
if (ref $message and UNIVERSAL::isa( $message, Locale::KeyedText::Message )) {
my $translator = Locale::KeyedText->new_translator( [SQL::Routine::L::], [en] );
my $user_text = $translator->translate_message( $message );
return q{internal error: cant find user text for a message: }
. $message->as_string() . . $translator->as_string();
if !$user_text;
return $user_text;
}
return $message; # if this isnt the right kind of object
}

Note that one key feature of SQL::Routine is that all of a models pieces are linked by references rather than by name as in SQL itself. For example, the name of the person table is only stored once internally; if, after executing all of the above code, you were to run "$tb_person->set_attribute( si_name, The Huddled Masses );", then all of the other parts of the model that referred to the table would not break, and an XML dump would show that all the references now say The Huddled Masses.

For some more (older) examples of SQL::Routine in use, see its test suite code.

WAVE Utilities package contains three programs for dealing with WAVE format audio files.
SimplifyWave
The standard permits WAVE format audio files to contain a variety of chunks, such as playlists, cue lists, and padding. A fair amount of software, however, is unable to parse such complex files. This program converts complex WAVE files into the simplest standard-conforming format by stripping out everything other than the obligatory format chunk and the first data chunk. Messages are printed indicating what chunks have been removed.
RepairWave
Some software generates non-conformant files that purport to be WAVE files. They contain a WAVE header but lack the obligatory data chunk id and size information. The audio data immediately follows the header. This program inserts the missing data chunk id and size information and updates the WAVE chunk size information in the header to reflect this.
InfoWave
Extracts information from a RIFF/WAV or RIFX/WAV file and reports on the contents of the file. It shows the size, type, and location of each chunk and gives the encoding of the audio data, its sampling rate, resolution, number of channels and other information. Typical output looks like this:
0: RIFF identifier.
4: chunk size = 38,642 bytes.
8: WAV identifier.
12: format chunk identifier
16: format chunk size = 18 bytes.
20: data format: PCM.
22: one channel (mono).
24: Sampling Rate = 11,025 samples per second.
28: Average Data Rate = 11,025 bytes per second.
32: Bytes_Per_Sample value of 1 indicates 8-bit mono
34: Bits_Per_Sample = 8.
36: chunk id
40: chunk length
44: chunk of type fact (standard) length 4 bytes
48: chunk id
52: chunk length
56: chunk of type data (standard) length 38,591 bytes
amounting to 0 minutes and 3.5 seconds
These programs were originally called SimplifyWav, wavrepair, and wavinfo.
Enhancements:
- The programs have been adapted to run correctly on 64-bit architectures as well as 32-bit architectures.
- They should now compile on systems whose printf does not support thousands separators.

muchine project is a small virtual machine that comes with its own assembler.
It features stackdump, memdump, and variable execution speed. Its actually a kind of programming exercise, and has a clean coding style.
Thus, it may be used for educational purposes.
Enhancements:
- GPL License notes inserted into source.
- Insert the vim:ts=3:sw=3 statements into all source files.
- Make it ready for uploading to sourveforge.net.

SYNOPSIS

use HyperWave::CSP;

$server = HyperWave::CSP->New("my.hyperwave.server");
$server->quit;

HyperWave is a class implementing a simple HyperWave client in Perl.

CONSTRUCTOR

new ( [ HOST [, PORT [, USERNAME [, PASSWORD [, ENCRYPT [, LANGUAGE ] ] ] ] ] ] )

This is the constructor for a new HyperWave object. HOST is the name of the remote host to which a HyperWave connection is required. If not given the environment variables HWHOST and then HGHOST are checked, and if a host is not found then localhost is used.

PORT is the HyperWave port to connect to, it defaults to the environment variable HWPORT, then HGPORT and then to the standard port 418 if nothing else is found.

USERNAME and PASSWORD are the HyperWave username and password, they default to anonymous. ENCRYPT will eventually allow you to pass the password in in encrypted form rather than plaintext, but is not yet implemented.

LANGUGAE also is not yet used, and defaults to the value of the environment variable HWLANGUAGE and then to English.
The constructor returns the open socket, or undef if an error has been encountered.

METHODS

Unless otherwise stated all methods return either a true or false value, with true meaning that the operation was a success. When a method states that it returns a value, failure will be returned as undef or an empty list.

command_stat ( )

Returns string containing various statistics for the server.

command_ftstat ( )

Returns string containing various statistics for the server.

command_dcstat ( )

Returns string containing various statistics for the server.

command_who ( )

Returns string containing current users for the server.

get_objnum_by_name ( NAME )

Returns object number for the document with NAME as an attribute, or false on error.

get_url ( OBJNUM )

Returns a guess at a URL that might work for the document OBJNUM to be retreived via the HyperWave HTTP interface. Note that it is ONLY a guess. For one thing, it depends on the HyperWave server running a web interface on the default HTTP port.

get_attributes ( OBJNUM )

Returns a string containing the attributes for OBJNUM. The string is in form key1=value1nkey2=value2n....

get_attributes_hash ( OBJNUM )

Like get_attributes() except that the attributes are returned as a hash.

get_text ( OBJNUM )

Returns body text for the objnum passed. This usually means HTML sans anchors in practical terms.

get_html ( OBJNUM )

Returns HTML text, including anchors, for the objnum passed.

exec_cgi ( OBJNUM )

Returns output of the CGI, for the objnum passed. Depends on the CGI script not requiring input.

insert_attribute ( OBJNUM, NAME, VALUE )

Adds an attribute to the given objnum. Note that HyperWave allows multiple attributes of the same name, so if you add an attribute that already exists youll end up with two. Use change_attribute if you want to overwrite the old one.

remove_attribute ( OBJNUM, NAME, VALUE )

Removes an attribute to the given objnum. Note that you DO need to know the old value because HyperWave allows multiple attributes with the same value.

change_attribute ( OBJNUM, NAME, OLD_VALUE, NEW_VALUE )

Alters an attribute to the given objnum (NB: needs to know old value).

get_children ( OBJNUM )

Returns objnums for all the children in the objnum passed. If the object was a leaf node (ie: no children) youll get a 0 back.

get_parents ( OBJNUM )

Returns objnums for all the parents in the objnum passed. If the object had no parents (it was the root collection) youll get a 0 back.

get_anchors ( OBJNUM )

Returns objnums for all the anchors in the document passed.

insert_object ( OBJRECORD );

Inserts an object on the HyperWave server. Returns object ID of the new object.

OBJRECORD should be in the form Attribute=AttributeValuenAttr2=Value2 and must contain certain parameters such as the parent object, name, document type, etc. It is suggested that you use one of the other insert_* commands as they provide a friendlier interface. This command is provided primarily for completeness.

insert_collection ( PARENT_OBJNUM, NAME [, OTHER_PARAMS ] )

Inserts a collection on the HyperWave server. Returns object ID of the new collection.

PARENT_OBJNUM is the object number (probably returned from get_objnum_by_name() of the collection to insert this collection into. NAME is the name attribute, this will become the apparent URL to somebody using the WaveMaster interface.
OTHER_PARAMS should be in the form Attribute=AttributeValuenAttr2=Value2 and so on. You might particularly want to set a Title for the collection.

insert_image ( OBJNUM, PARENT, NAME )

Adds a new picture. NOT YET IMPLEMENTED.

insert_text ( OBJNUM, PARENT )

Adds a new text object (no anchors). NOT YET IMPLEMENTED.

insert_html ( OBJNUM )

Adds a new html object (we parse the anchors). NOT YET IMPLEMENTED.

error ( )

Returns a human-readable string describing the previous server error.

server_error_message ( )

Returns a human-readable string describing the previous server error.