Hi, I have been thinking about this comment of yours.
The URI class manipulates the "Identifier". Note what the actual related acronyms mean. http://www.w3.org/Addressing/ http://www.w3.org/Addressing/URL/1_NeedUniversal.html http://www.w3.org/Addressing/URL/URI_Overview.html * URI - Uniform Resource Identifier http://www.ietf.org/rfc/rfc2396.txt Uniform Resource Identifiers (URI) provide a simple and extensible means for identifying a resource. * URL - Uniform Resource Locator * URN - Uniform Resource Name (Please note that the word "Uniform" is frequently replaced by "Universal" without any particular loss of correctness.) Meanwhile, you want to access the Resource, not simply manipulate its Identifier. Your question seems to suggest that there should be a class (perhaps P5EEx::Blue::UniversalResource) which has the properties that you suggest. (On the other hand, it should almost certainly be developed outside the P5EE namespace because it has general value.) It might have a usage as follows. use UniversalResource; $uri = "http://www.officevision.com/pub/p5ee/index.html"; $ur = UniversalResource->new($uri); $content_type = $ur->content_type(); $content = $ur->content(); # return the binary data $handle = $ur->handle(); # return an IO::Handle to read the data $uri2 = "http://www.officevision.com/pub/p5ee/images/logo.png"; $ur2 = UniversalResource->new($uri2); $img = $ur->content_as_object(); # return a Perl class often used # to operate on such data (such as "GD") Is this what you are getting at? I intend that all Entity Widgets will be identifiable by URL's so that they can be accessed from anywhere within the network (by reference or by value). Stephen At 01:21 PM 2/25/2002 +0900, Tatsuhiko Miyagawa wrote: >I definitely believe URI resource manipulation is what p5ee should >discuss about, but I couldn't find API draft for it. (So point me if I >miss anything.) > >In a word, why does URI module miss "get_data()" (or get_handle()) >method? > >As a module writer, it's bothered me how to define API which points to >some "resource". For example in Mac::Macbinary, new() accepts three >type of argument: > > 1. file path (like /path/to/file) > 2. file handle (or IO::* object) > 3. raw data as a scalar reference > >So it results in ugly if ... elsif ... elsif ... in new(). > >As a module user, it's botherd me how to pass argument to module, >without a hassle in looking at module's perldoc. So if I get data via >HTTP and convert it with Some::Conv which accepts raw data as a scalar >reference, I should code something like: > > use LWP::Simple; > use Some::Conv; > > my $data = get $url; > my $conv = Some::Conv->new(\$data); > >What bothers me is inconsistency of API amongst various modules. So we >need Universal API to define some "resource". It is what URI is about. > >Defining get_data() or get_handle() in URI class will reduce these >hassles amongst module's developers/users: > > my $uri = URI->new('file://path/to/file'); > my $data = Some::Module->new($uri); > > >SEE ALSO: >* URI class in Java > http://java.sun.com/j2se/1.4/docs/api/java/net/URI.html >* fopen() function in PHP > http://www.php.net/manual/en/function.fopen.php > >-- >Tatsuhiko Miyagawa > >