in reply to General Transformation API
I see many pitfalls for a General Conversion API, or rather only a single, as it will be either too generic, because it has to accomodate everything, or too special for its title.
The pipelines I know are:
As long as you reduce your problem domain close enough, you can keep most of the meta-data problem out of your house, as the meta-data is common to all filters involved.
As soon as you go "general", your filter API can be reduced to the following interface:
sub filter::can_connect_to { my ($self,$input) = @_; return 1; }; sub filter::connect_output { my ($self,$next_filter) = @_; # ... do magic }; sub filter::on_input_connect { my ($self,$input) = @_; }; sub filter::process { my ($self, $data) = @_; # ... do magic }; sub filter::describe { return "Magic filter"; };
This hides all the "arbitration magic" in the connect and on_connect methods, where both filters have to decide on something they can do to each other... I think that without a specific goal, you won't get far with a general concept.
perl -MHTTP::Daemon -MHTTP::Response -MLWP::Simple -e ' ; # The $d = new HTTP::Daemon and fork and getprint $d->url and exit;#spider ($c = $d->accept())->get_request(); $c->send_response( new #in the HTTP::Response(200,$_,$_,qq(Just another Perl hacker\n))); ' # web
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re: Re: General Transformation API
by liz (Monsignor) on Oct 23, 2003 at 18:04 UTC |