Re: production mail server in Perl, was Re: asynchronous execution
On Wednesday, Mar 19, 2003, at 14:27 Europe/London, Ask Bjoern Hansen wrote: [EMAIL PROTECTED] (Bas A . Schulte) writes: [...] Would be great to have a good generic server framework upon which other types of servers could be built. (slightly old thread) I keep meaning to make qpsmtpd run under mod_perl 2, but I haven't had the tuits for it yet. What would be the benefits? Matt.
Re: Concept for an Apache/mod_perl Perl Application Server
On Tuesday, Nov 26, 2002, at 16:45 Europe/London, Stephen Adkins wrote: Others tend to concur. Bas Schulte http://archive.develooper.com/p5ee%40perl.org/msg01195.html Matt Sergeant http://archive.develooper.com/p5ee%40perl.org/msg01191.html No, I've always thought Apache was a terrible place to put this sort of thing. People used to advocate the whole cron thing to me on the mod_perl list, and I always wanted for a better solution. My preference is POE. Matt.
Re: Concept for an Apache/mod_perl Perl Application Server
On Tuesday, Nov 26, 2002, at 17:41 Europe/London, Bas A.Schulte wrote: I did take a look at POE, and still do now and then, but I just don't seem to get it's concepts to actually get something done on top of it. Recently I tried one of the examples on poe.perl.org (http://poe.perl.org/?Poe_cookbook/Web_Server_With_Forking) briefly but it wasn't very fast, even for NOOP requests. POE isn't terribly fast, because it has to do a lot of management on top of its server system. Where you gain is in sharing - you don't have to jump through hoops to share data (except in a multi-server system). Matt.
Re: protocol explosion (was asynchronous execution, was Re: implementing a set of queue-processing servers)
On Friday, Nov 22, 2002, at 02:49 Europe/London, Gunther Birznieks wrote: I disagree. I think it depends on the protocol. A well designed protocol for an application will spread and stand the test of time. Sometimes the protocol doesn't have to be well designed, but just that it's standard can help tremendously. eg if we were a world that said HTTP is it and we should do everything over HTTP, then would you really see SMTP over HTTP? SNMP over HTTP? telnet over HTTP? Why? This doesn't really make sense to me. [OT, because I know this isn't really your point] As someone who's entire job revolves around SMTP these days, I'd love to see mail go over HTTP. SMTP's got no concept of negotiation. It's got little in the way of versioning (HELO vs EHLO). It's got no permanent redirect (e.g. [EMAIL PROTECTED] is now [EMAIL PROTECTED]). It's got very weak handling of binary data. Writing mail server plugins is very non-standardised. Don't get me wrong, SMTP is a great protocol, but HTTP is sometimes just *so* much nicer :-) Matt.
Re: Aspect-Oriented Programming with Perl 5.8.0
On Wednesday, Oct 30, 2002, at 04:34 Europe/London, Stephen Adkins wrote: What I really want is the ability to do the following. * Turn on tracing, where a program will print out every function/method entry and exit in indented form to show the program flow. Sounds like you want Devel::TraceCalls. http://search.cpan.org/author/RBS/Devel-TraceCalls-0.03/
Re: OSCON 2002 P5EE BOF
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday 11 June 2002 11:06 pm, Stephen Adkins wrote: 2. I had figured it would be in a conference room where we had some hope of getting a speaker phone in there so I could perhaps join in remotely. Anyone know how the BOF format works? Will it be around a table? at a lectern? or just pulling together a circle of chairs? Depends on the size of the room mostly, but usually in the evening all the AV stuff is taken away or turned off, so you're on your own if you want a mic or speaker phone or anything like that. At the CMS BOF two years ago loads of people turned up, so we used the whole room in the same layout as when speakers were in earlier, at smaller BOF's I've been to we just grabbed chairs and sat around. - -- :-get a SMart net/:- -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9BnVwVBc71ct6OywRAnNZAJ0ZGJgsCnJqG++6bw5Xzd7MMqMuOACfcoJ3 3ArJ9XvvzFUhnXWptU8FIFU= =phZN -END PGP SIGNATURE-
Re: A reminder of why we're here...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sunday 09 June 2002 7:34 pm, Greg McCarroll wrote: * Perrin Harkins ([EMAIL PROTECTED]) wrote: However, J2EE is mostly used for server-side web development, and that's what I was talking about. There's no need for any distributed object technology there about 99% of the time. This is probably as good a place as anywhere for this conversation ... I was talking to a TA from Accenture recently about Perl, mod_perl and Java and he told me that some java application server (i forgot to ask him which) could maintain less JDBC connections than http session handling threads and share them between the threads as needed without prior knowledge of wheter or not the thread needed to do DB work. Is there an equivalent way to do this with mod_perl? To my knowledge, which may be wrong, there isn't[1]. Apparently it's possible with Sybase (Michael Peppler has done something special to support this under mod_perl, but I don't recall exactly what, and I think he has to use the Sybase CtLib or DbLib directly rather than DBI). The details are somewhere deep in the mod_perl list around about a year ago. - -- :-get a SMart net/:- -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9A7AqVBc71ct6OywRAuYKAJoDT1mJ+NoqP2p7ZYsG0/K4+HlGJgCfSByX K6PlTTRXxT9judg9/1l5mNQ= =8Jkg -END PGP SIGNATURE-
P5EEx::Blue critique
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OK, I'm just going to go through all the bad stuff I see in Blue, because that's what I'm good at. Sorry if that seems harsh. Overall === Overall I would say P5EEx::Blue's biggest problem is that it is entirely designed from the perspective of web development, and I think it suffers because of that. Generally it's great that this has got off the ground, but now a lot more work needs to be done - this isn't even ready to be 0.01 yet - if we released this to the world at large the J2EE community would laugh at us. Config == o get_branch should return a new Config object, not a hashref. o There is no reload() method. o There are no setters. Context === o Context knows *way* too much about widgets. It shouldn't know anything at all about them. Put that stuff in a subclass if you have to. o There seems to be a lot of convenience methods in there. I think this is confusing right now. o There's both debugging and logging. Why separate the two? Why are they even in this class? LogChannel == o There is only a single log level. This is fatal. See Log::Dispatch (and Log::Dispatch::Config) for a better design. Messaging = o I don't know enough about messaging APIs to really comment on this. I get the feeling that the API is naive, but it's merely a gut feeling. Procedure = o Do we need this class? I'm not convinced we do. It seems again like a naive design - I'd like to see what j2ee does in this space. Repository == o This seems to be yet another DBI abstraction layer. It seems quite tied to the concept of relational databases (or at least - relational data). What are the rules for the $params option? If that's subclass dependant it seems kinda pointless. Security Seems unstarted, which is a shame as this is one of the nuts-and-bolts parts of an enterprise environment. Serializer (ugh, american spelling ;-) == o We need a facility to serialize directly to a filehandle (even if it's implemented as a serialize to string and then writing to a file), and directly to callbacks. Session === o html() method *must* die. o This seems like a place where p5ee could be really strong, but it's not. Sessions require facilities like timeouts, getters/setters, and a few more bits. SharedDatastore === o A SharedDatastore service represents a single hash in which scalars or deep references may be stored. (They are automatically serialized using Storable for storage.) - Why are they not serialized using Serializer? Or is this a doc bug? o How do we define where the shared data is, what the limits are, and what timeouts exist? SharedResourceSet = o Looks good. No complaints ;-) TemplateEngine == o I'm not sure I like this, or even think it should be in p5ee. Templating often works extremely differently depending on the environment you're in, and the templating system in use. One of the biggest plusses for XSLT (for example) is that the result of an XSLT transformation is a new XML DOM tree, not a string, as you have it in your API. I'd say leave this out of p5ee. Widgets === Ah, the widgets... I have a feeling that this is where you spent most of the development effort. I've spent a lot of time studying and trying different techniques of doing cross-environment widgets, and it just plain don't work. Right now all you have is Widget::HTML::*. When you get to trying to do Widget::Gtk, or supporting some of the Gtk features in HTML, and trying to be a transparent layer between Gtk and Tk, you'll see it just doesn't and can't work. These different layers are so fundamentally different that no layer over the top of them can just make them work. While I think the Widgets stuff is an excellent separate project, I think it has no place in p5ee, unless everyone thinks that p5ee should be focussing on web development? Docs The docs are nice (albeit lacking detail). Good work on those. Conclusions === I hope I haven't been too harsh. All in all I'm +1 to make P5EEx::Blue the start of P5EE (bet you weren't expecting that!). The reason being that we need to start somewhere, and Stephen obviously has a lot of energy for this project where the rest of us don't. But I think it's going to need major surgery, and a serious effort from more than just Stephen (and no, that's not me volunteering ;-) - -- :-get a SMart net/:- -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE84hg0VBc71ct6OywRAqg2AKDQjzoJD/oL5IaJZL4zeICS+2yypQCgiS6P zckeIhTFnCylAzYR4eXaOcs= =M0mf -END PGP SIGNATURE-
Re: Preparations for a Vote
On Tuesday 14 May 2002 11:35 pm, Stephen Adkins wrote: At 12:27 PM 5/11/2002 -0400, Stephen Adkins wrote: Hi, In preparation for a vote, I am requesting input from *everyone* on this list who engages in web application development or anything approximating enterprise development. I am being deafened by silence. So here is an additional qualification for voting: You must respond to my message (your answers may be brief) and/or participate in this discussion in order to qualify to vote later (I reserve the right make exceptions, but they will need to be for good reasons). I have actually gotten three off-list responses. Please respond via the list rather than privately. None of the people who showed great interest at the outset of this project have responded. (I guess the 6 month delay chased away everyone who showed initial interest.) We are not deterred. The P5EE bandwagon rolls on. I had a brief look at the code, but gave up when I saw that there were no tests. Sorry, but that's as far as I got. Then real life took over ;-) Matt.
Re: Post about a Apache/mod_perl based component/service architecture
On Fri, 22 Mar 2002, brian moseley wrote: On Fri, 22 Mar 2002, Matt Sergeant wrote: The problem with lack of timers and in the future events made me switch a lot of my server work from mod_perl to POE. Despite your fears about cooperative multitasking (yes it's a pain, but there are work-arounds), it's a very nice platform to develop for, IMHO. every time i look at poe my head spins and i am reminded exactly how much of a novice i really am. I had this problem too, until I figured out that it's just terminology that was confusing me. That's why I'm giving a POE tutorial at the perl conference this year to help clear up some of this confusion. Conceptually POE is actually really simple, once you get past the documentation ;-) -- !-- Matt -- :-Get a smart net/:-
Re: [Cross-Post] Perl Widget Library = P5EE
On Thu, 21 Mar 2002, Stephen Adkins wrote: P.S. I have begun work on P5EEx::Blue::TemplateEngine::TemplateToolkit. If anyone who knows Mason or AxKit would like to help, I would be happy for you to work on P5EEx::Blue::TemplateEngine::Mason or P5EEx::Blue::TemplateEngine::AxKit. AxKit is not a template engine. -- !-- Matt -- :-Get a smart net/:-
Re: P5EEx::Blue ready for alpha users
On Tue, 19 Mar 2002, Richard Dice wrote: Have you taken a look at http://www.smartworker.org/ ? that site has no whitepapers or modues to download. I checked gozer's author directory: http://search.cpan.org/search?mode=authorquery=gozer and saw no web kit there either. Hmm. I'm not sure what the state of maintenance (or even availability) of the SmartWorker kit is these days. Gozer and Bbeausej have both has much more recent contact with it than I have. (Bb especially) There was once an tarball of Smartworker on CPAN, though I forgot who was its maintainer (probably either Gozer or Scott Wilson). But the CPAN search I did just now yielded nothing. It's in the SMARTWORKER author directory if I remember correctly. Hmm, it seems to have dropped off CPAN. Not unusual when a module isn't updated. I had a long conversation with Gozer about SW. Basically we discussed ways you could improve it to use XML (well, duh!), and to be more MVC in nature. Unfortunately neither of us went anywhere with it, but Gozer said he intended to do a complete rewrite at some point. -- !-- Matt -- :-Get a smart net/:-
Re: bivio online transaction processing system
On 28 Feb 2002, Michael A Nachbaur wrote: One thing that Pg offers that nobody else does is Perl stored procedures I haven't had the opportunity to try them yet, but it sounds very cool indeed to be able to write SPs in Perl Has anyone here used those yet? I've toyed with them a bit, but for security purposes, the verison of perl that is linked in with Pg cannot access external files or system calls As a result, you can't require or use any external libraries Also, another real bummer, is you can't actually invoke any SQL queries from within a perl stored procedure All you can do is things like regex's and other stuff on your input arguments There's a module on CPAN allowing you to do SQL from within PL SP's -- !-- Matt -- :-Get a smart net/:-
Re: stored procs? why?
On Thu, 28 Feb 2002, brian moseley wrote: On Fri, 1 Mar 2002, Matt Sergeant wrote: Given that though, it becomes very easy to see that if you do have a large transaction (including multiple table updates for example), it's often safer to encapsulate that into a single stored procedure than it is to write some large chunk of Perl that turns off AutoCommit, does the work, and then commits Plus it ensures people can use other languages to execute the same transaction If you want to use SOAP/HTTP to emulate a stored procedure to achieve the same effect you're welcome to, but beware of the performance beware the tremendously inflated development schedules that can result from this approach at critical path, we used a lot of pl/sql stored procs for validation, integrity checks and transactions almost every development schedule for adding or modifying features to the service was blown out by the stored proc development effort Compared to hacking perl code - absolutely Plus SP's are almost always harder to debug Nothing is without tradeoffs - this is why you still need people who know their stuff working for you ;-) -- !-- Matt -- :-Get a smart net/:-
Re: bivio online transaction processing system
On Wed, 27 Feb 2002, Ajit Deshpande wrote: On Wed, Feb 27, 2002 at 08:27:28AM -0500, Chris Winters wrote: On Tue, 2002-02-26 at 22:41, Rob Nagler wrote: Depends on what you mean by need. If you need row-level locking or a standby database, it's Oracle or DB2 afaik. I think this kind of begs the question :-) Do most apps *need* these features? It's the same kind of attitude I mentioned above: Oracle is the answer to every question. Even if you just have 200 MB and no more than 50 max concurrent users doing normal browse/create/update operations, and normal backup operations will be just fine. (And IIRC, I believe that Sybase ASE, Sybase ASA, Microsoft SQL Server, and PostgreSQL all have row-level locking or versions implementing the same concept.) MySQL with the new InnoDB type tables has row-level locking with full transaction support as well.. More to the point, Oracle doesn't use row level locking, it uses MVCC, the same as PostgreSQL does. By far a more advanced model, IMHO. -- !-- Matt -- :-Get a smart net/:-
Re: what is the object in DBI OO-database development?
On Wed, 27 Feb 2002, Dave Rolsky wrote: On Wed, 27 Feb 2002, Matt Sergeant wrote: Right, so how would I go about writing an application that used Class::DBI that absolutely needed outer joins (say, for example, a bulletin board type application that supported anonymous postings), and I wanted it to work cross platform? Just like with DBIx::AnyDBD, you'd have to have one subclass per RDBMS, and custom code it for each (well, actually MySQL and Postgres share the same syntax for outer joins these days). But with Alzabo you wouldn't need to do that! Of course, it only support MySQL and Pg right now ;) Right, and only on Unix (i.e. not transparent through ODBC/ADO). This is why I said broken in an earlier email. -- !-- Matt -- :-Get a smart net/:-
Re: what is the object in DBI OO-database development?
On Wed, 27 Feb 2002, Dave Rolsky wrote: You've lost me. Nothing prevents you from having Class::DBI or Alazbo use ODBC or ADO on Windows or any other OS. No, but most database abstractions treat ODBC naively as a whole, not a passthrough interface through which you access other databases. Thus abstractions tend to have generic ODBC classes, rather than doing what AnyDBD does and figures out the underlying database you're connecting to, and using the appropriate class for that DB. _Right now_, Alzabo only supports MySQL and Pg directly. If you wanted to use Alzabo with ODBC, you'd have to write a certain amount of code to enable it do so. OTOH, If you used DBIx::AnyDBD, which already works with ODBC, you'd have to write a lot of SQL (depending on how complex your app is) that you wouldn't have to write with Alzabo. Either way you'd have to write some code. With Alzabo, once it existed you could reuse it for your next ODBC app. With DBIx::AnyDBD, you'd have to write custom SQL every time. I'm not suggesting people use AnyDBD to write apps with (I do suggest it regularly, but that's not what I was discussing here). I was talking about frameworks. Alzabo (and other DB abstractions) should use DBIx::AnyDBD for it's internal database abstraction. That's all I'm suggesting here. -- !-- Matt -- :-Get a smart net/:-
Re: bivio online transaction processing system
On 28 Feb 2002, Ilya Martynov wrote: On Wed, 27 Feb 2002 13:12:22 + (GMT), Matt Sergeant [EMAIL PROTECTED] said: MySQL with the new InnoDB type tables has row-level locking with full transaction support as well.. MS More to the point, Oracle doesn't use row level locking, it uses MVCC, the MS same as PostgreSQL does. By far a more advanced model, IMHO. Actually InnoDB like Oracle is not just row-level locking. It is MVCC also. Yeah I just found that out. Very cool. Also note eweek's latest benchmark showing MySQL to be as fast and scaleable as Oracle 9i (using JDBC though). One thing that Pg offers that nobody else does is Perl stored procedures. I haven't had the opportunity to try them yet, but it sounds very cool indeed to be able to write SPs in Perl. Has anyone here used those yet? -- !-- Matt -- :-Get a smart net/:-
Re: what is the object in DBI OO-database development?
On Tue, 26 Feb 2002, Terrence Brannon wrote:
Perspective 1: The DBIx::AnyDBD approach (a DBI core solution)
The database is an object. Your perl program contains the methods
which manipulate the object.
E.g.:
my $app_handle = DBIx::AnyDBD-new( ... ) ;
my @cds =
$app_handle-load_new_cd_releases_since($cgi-param('date')); #
SELECT
$app_handle-store_new_cd(%cd_data);# INSERT
Perspective 2: The Object-Relational Approach (based on DBI,
but not core. found in several modules -
Class::DBI, Tangram, BingoX::Carbon, SPOPS).
E.g.:
my $cd_set = CD-new;
my @cds = $cd_set-since($cgi-param('date')); # SELECT
my $cd = CD-new(%cd_data); #INSERT
$cd-save;
What surprises me is that more of the Type2 solutions don't use
DBIx::AnyDBD to provide their database abstraction stuff. AnyDBD provides
some nice facilities for seeing through ODBC connections, yet all the
Type2 solutions roll their own (and inevitably get it slightly wrong, or
make supporting other DB's take months, not days).
Just MHO, of course.
I'd have gone for OR mappers any day for my projects if I thought they
could support enough DBMS's, and worked fast enough. But sometimes you
just have to optimise the SQL for a particular database - that's just the
way it works with RDBMS's.
--
!-- Matt --
:-Get a smart net/:-
Re: autogeneration of CHANGES file
On Fri, 1 Feb 2002, Dave Rolsky wrote: On Fri, 1 Feb 2002, Stephen Adkins wrote: Unless there is a clear consensus on how to do this, I will probably modify my cvshistory script to create the CHANGES file. (cvshistory is the script which creates the CVS Activity page and is located in the P5EEx/Blue/sbin directory.) http://www.officevision.com/pub/p5ee/activity.html I really hate seeing changelogs that are collections of CVS comments. You end up with lots of stuff like: Rewrote algorithm to detect smells Tweaked some variable names ... They tend to be way too low level to be of interest to non-core developers, people who just use the stuff. When I look at a changelog for a Perl module, I want to to see what will affect me. Faster, more features, API changes, etc. And that's it. Take the time to write a changelog by hand based on the CVS changes or something. I'm totally with you on that (though don't do what I do and *forget* to update Changes - does anyone have a MY::dist that asks you if you updated Changes and $VERSION and cvs tag???). If people want CVS changes provide anon cvs and let them do cvs log. -- !-- Matt -- :-Get a smart net/:-
Re: Class::Base
On Tue, 15 Jan 2002, brian moseley wrote: On Tue, 15 Jan 2002 [EMAIL PROTECTED] wrote: Did somebody think about extending Attribute::Type so that it supports nested structures (and you could get a real type system from that) ? i'm pretty sure there was concensus in a previous thread that requiring 5.6.1 in order to get attribute support is not desired. It wasn't exactly clearly debated, or voted on. One thing I didn't mention in that thread, which has just bitten me in the bum again (in someone else's code) is circular references. Which 5.6.x solves quite nicely with the WeakRef module (not core, but on CPAN). -- !-- Matt -- :-Get a smart net/:-
Re: Class::Base
On Tue, 15 Jan 2002, brian moseley wrote: On Tue, 15 Jan 2002, Matt Sergeant wrote: One thing I didn't mention in that thread, which has just bitten me in the bum again (in someone else's code) is circular references. Which 5.6.x solves quite nicely with the WeakRef module (not core, but on CPAN). ok, here's a tangent. in the last 24 hours i've been really irritated by the fact that i have to dig up 18 different modules (sometimes of dubious quality) to get behavior that i really wish was in core. what's happening is that i'm building a list of modules that i'm going to wind up including in every single module i ever write! Attributes::This and Class::That. what a pain! maybe i should mimic andy and make Class::Everything. The end result being p5ee! That's the point - core don't want to include a whole bunch of modules that will never get updated. But people want something to point to to say: There's the quality bits. That's why we're here, right? -- !-- Matt -- :-Get a smart net/:-
Re: Class::Base
On Mon, 14 Jan 2002, brian moseley wrote: Class::Base got uploaded to cpan this week. thoughts? http://search.cpan.org/search?mode=modulequery=Class%3A%3ABase I was surprised by this, being an Andy Wardley module I expected it to be a lot more all encompassing (if you're listening, Hi Andy!). Whereas in fact it simply seems to create a new hashref object and call init() if it's available. That's all it does (unless I'm very much mistaken). -- !-- Matt -- :-Get a smart net/:-
Re: Class::Base
On Mon, 14 Jan 2002, brian moseley wrote: On Mon, 14 Jan 2002, Matt Sergeant wrote: I was surprised by this, being an Andy Wardley module I expected it to be a lot more all encompassing (if you're listening, Hi Andy!). Whereas in fact it simply seems to create a new hashref object and call init() if it's available. That's all it does (unless I'm very much mistaken). there's some error handling too: my $obj = My::Object-new or die $0: whoops: . My::Object-error; and there's a little bit of useful code for handling either hashrefs or hashes of named args in the constructor. that's code which is irritating to cut and paste over and over, to be sure. what else would be useful but general enough? clone(), equals(), to_string() come to mind.. (this is based on java.lang.Object, sorry folks) equals class to_string clone There's some other more Java-ish stuff, but I think that'll do. -- !-- Matt -- :-Get a smart net/:-
Re: Licensing IP ( was Re: Messaging [and licensing] )
On Mon, 26 Nov 2001, Gunther Birznieks wrote: At 11:10 PM 11/25/2001, Matt Sergeant wrote: On Sun, 25 Nov 2001, Gunther Birznieks wrote: This is identical to an interview I read a few weeks ago with SleepyCat (the Berkeley DB folks)... As a company, it's in our best interest to use an overly aggressive open source license that forces commercial entities to buy a less restrictive one. As an open source group though who is building a project precisely intended to be used in commercial large scale products, then we want a less restrictive license and I would argue against GPL. Actually in many ways, the GPL might be a good thing for P5EE, and if not, then the LGPL. We certainly don't want entities taking the P5EE stuff, modifying it, and selling solutions based on modified versions. That would defeat the purpose. So the LGPL gives us some power over that. Why not? Because P5EE should be like J2EE that way - all about stability of the API, making sure you can carry the knowledge to the next job. Or port to another P5EE framework. If some company modifies it, then it dilutes the skillpool. -- Matt/ /||** Founder and CTO ** ** http://axkit.com/ ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** mod_perl news and resources: http://take23.org ** \\// //\\ // \\
Re: Name for Perl beans
On Sun, 25 Nov 2001, Uri Guttman wrote: well, in a moment of perspiration, this name came up: perl onions. Smelly, and make you cry. -- Matt/ /||** Founder and CTO ** ** http://axkit.com/ ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** mod_perl news and resources: http://take23.org ** \\// //\\ // \\
Re: a sample of the p5ee docs generated with DocSet
On Fri, 23 Nov 2001, Stas Bekman wrote: It took me a few minutes to setup the docset for p5ee, check out the auto-generated HTML: http://www.apache.org/~stas/p5ee/dst_html/ It's all very pretty, but it doesn't cover the docs issues we have been discussing here - method parameters, class interactions, automatic inter-module links, etc. Or did I miss something? -- Matt/ /||** Founder and CTO ** ** http://axkit.com/ ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** mod_perl news and resources: http://take23.org ** \\// //\\ // \\
Re: P5EE::Util::DateTime (?!?)
On Fri, 16 Nov 2001, Gerald Richter wrote: Time::Piece was once into core, but has been retracted now. Do you know the reasons why ? Jarkko didn't want to be responsible for defining the One True Date/Time Module, since it's such a religeous issue. So despite it being Larry's design, he backed out. -- Matt/ /||** Founder and CTO ** ** http://axkit.com/ ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** mod_perl news and resources: http://take23.org ** \\// //\\ // \\
Re: P5EE::Util::DateTime (?!?)
On Fri, 16 Nov 2001, Stephen Adkins wrote: Hi, It says in the documentation for Class::Date that it was derived from Time::Object (from the Time::Piece distribution). Does anyone know why? Why was Time::Object not simply extended? We had a fight about the code. His code is horrible, really quite ugly. So I wouldn't accept his patches. We also fought about what should be in the project's scope. I wanted Time::Object(Piece) to be simple, and he wanted it to do all sorts of things like be able to automatically handle MySQL's date format (?!!). -- Matt/ /||** Founder and CTO ** ** http://axkit.com/ ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** mod_perl news and resources: http://take23.org ** \\// //\\ // \\
Re: P5EE::Util::DateTime (?!?)
On Thu, 15 Nov 2001, Jonathan Stowe wrote: On Thu, 15 Nov 2001, brian moseley wrote: On Thu, 15 Nov 2001, Stephen Adkins wrote: Use the following modules for dates and times Class::Date Date::Parse Date::Format i propose that we make this our official recommendation for p5ee software and that we accept proposals for altering the recommendation as they occur. advocate type=devils I'm not actually sure this is something that should be set in stone here right now. I'm totally with Greg in his point that this project should be focussed on the middle tier space, but I would also like to suggest that this implies that we can make no assumptions about the implementation platform of the adjoining tiers in the application. There may be compelling reasons for me to implement my UI layer in Java and my data storage layer in C++ or Ada, I'm going to be looking at interoperability as a key feature in the platform I use to implement the stuff between them. So for instance could any of this stuff pick the bits out of : prop:sentAt2000-05-14T03:00:00+08:00/prop:sentAt This is ISO 8601 format. For Time::Piece it's just $t-datetime(), since it's such a standard formatting. We talked about making it the default stringification, but that would have made it incompatible with localtime(). -- Matt/ /||** Founder and CTO ** ** http://axkit.com/ ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** mod_perl news and resources: http://take23.org ** \\// //\\ // \\
Re: P5EE::Util::DateTime (?!?)
On Thu, 15 Nov 2001, Aaron Johnson wrote:
+1 on Time::Piece. I like the more verbose example Gerald gave:
$date3= $date+{years=1,months=2,days=3};
FWIW, I would never support this directly, because the rhs is a hash, not
an object or a number. But I would support:
$date3 = $date + Time::Seconds-new({years = 1, months = 3, days = 3});
--
Matt/
/||** Founder and CTO ** ** http://axkit.com/ **
//||** AxKit.com Ltd ** ** XML Application Serving **
// ||** http://axkit.org ** ** XSLT, XPathScript, XSP **
// \\| // ** mod_perl news and resources: http://take23.org **
\\//
//\\
// \\
Re: P5EE::Util::DateTime (?!?)
On Wed, 14 Nov 2001, Stephen Adkins wrote: At 04:51 PM 11/14/2001 +, Matt Sergeant wrote: On Wed, 14 Nov 2001, Stephen Adkins wrote: Hi, * Is anyone interested in helping sort out Date and Time functionality for the P5EE? No. This is *not* an enterprise API, IMO. Others may feel differently, but we're not here to sort out all of CPAN! That is a good point which we should keep in mind to keep us focused. Nonetheless, one might hold (as I do) that it really should be part of the language (date/time manipulation) as it is in Java. (Hence my suggestion of the P5EE::Lang::* namespace.) In that case I suggest Time::Piece :-) -- Matt/ /||** Founder and CTO ** ** http://axkit.com/ ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** mod_perl news and resources: http://take23.org ** \\// //\\ // \\
Re: P5EE::Util::DateTime (?!?)
On Thu, 15 Nov 2001, Stephen Adkins wrote: Hi, Thanks for everybody's input (I pretty much got slammed on this one). ;-) (see the condensed discussion thread at bottom) No matter. I gladly table this discussion until (if/when) there is some actual code to vote on. Code speaks louder than words. This is what my conclusion is from the discussion. Use the following modules for dates and times Class::Date Date::Parse Date::Format Can anyone explain what these 3 modules gain me over the 1 module Time::Piece? -- Matt/ /||** Founder and CTO ** ** http://axkit.com/ ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** mod_perl news and resources: http://take23.org ** \\// //\\ // \\
Re: Inline POD vs. External POD
On Sat, 10 Nov 2001, Stephen Adkins wrote: Hi, What experiences to people have with using inline POD within the Module.pm as opposed to maintaining two files, Module.pm (for code) and Module.pod (for documentation)? What recommendations would you have for P5EE code? I would assume Inline POD is the way to go. I am wondering if anyone has experiences counter to this. This is going to be an area of contention... I think POD has to go for this project. At least in its default form. We need something way more structured, that maintains API details to the extreme, like JavaDOC does, only we want something easier/better than JavaDOC. I'd suggest XML for docs, in particular sdocbook (simple docbook), but I know it gives people hives, so maybe an extended POD format would work (but it starts to get real ugly when you extend it to this extent). -- Matt/ /||** Founder and CTO ** ** http://axkit.com/ ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** mod_perl news and resources: http://take23.org ** \\// //\\ // \\
Re: some observations, and a proposed project
On Thu, 8 Nov 2001, Perrin Harkins wrote:
my only concrete reason for preferring xml, other than that
it feels right ;), is that you get much better error
handling right out of the box, especially when you turn on
validation. that's something that would have to be
implemented as part of a perl-based config file processor.
Can't you just do something like a require() wrapped in an eval{}?
I'm not against an XML config, although I've always been happy with perl
config files in the past. (I still want to see the layered config idea that
was discussed earlier.) It may be that a CGI implementation would need to
cache the data with Storable and stat the XML files to see if they've
changed.
One thing to bear in mind is the size of an XML parser. XML::SAX::PurePerl
is running at about 2500 lines of code at the moment, which could be seen
as pretty heavyweight for a core component. Then again, it could be
considerably smaller than, say, a fully fledged mail API.
We may wish to consider either simple INI files (which is what I'm using
to bootstrap XML::SAX, see the perl-xml list for details), or something
like Ingy's XML-come-Data-Dumper-come-Python config files. I forget what
it's called right now (MinML?).
But having said that, I agree with the validation thing - but there aren't
many validating XML parsers in perl.
--
Matt/
/||** Founder and CTO ** ** http://axkit.com/ **
//||** AxKit.com Ltd ** ** XML Application Serving **
// ||** http://axkit.org ** ** XSLT, XPathScript, XSP **
// \\| // ** mod_perl news and resources: http://take23.org **
\\//
//\\
// \\
Re: some observations, and a proposed project
On Thu, 8 Nov 2001, Perrin Harkins wrote: And then try finding the errors. Perl compile errors generally have nice messages with line numbers, but whatever, XML is fine with me for this type of project. I just think you guys are being too hard on a technique that has served generations of Perl coders well. Instant config files are really handy, and I've wished for them more than once when working in Java. java.util.Properties? -- Matt/ /||** Founder and CTO ** ** http://axkit.com/ ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** mod_perl news and resources: http://take23.org ** \\// //\\ // \\
Re: Method (n|g)ames
On Sun, 4 Nov 2001, Jonathan Stowe wrote: On Sun, 4 Nov 2001, Matt Sergeant wrote: I'm totally against the use of AUTOLOAD. I must admit I thought it was cute seeing it used in Damian Conway's book to generate accessors on the fly, but really, all it's doing is saving a tiny bit of typing. Well not everywhere. For some of the stuff I have been doing it saves you from having to remember to change things when you add new columns to a database table for instance. Even so, P5EE is at the infrastructure level, not the application level. We should use best practices, and I don't think AUTOLOAD fits into best practices. Look, we need some sort of voting procedure here, otherwise we're going to go back and forth with issues like this. What scares me is we have at the moment a situation similar to the Perl 6 process, whereby anyone can throw ideas out. But we don't have a Larry, who we (well, most people) trust. And we don't have an Apache-like meritocracy. So how do we make decisions? -- Matt/ /||** Founder and CTO ** ** http://axkit.com/ ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** mod_perl news and resources: http://take23.org ** \\// //\\ // \\
Re: servlet api conversion
On Thu, 1 Nov 2001, brian moseley wrote: in re character encodings and conversions, my current plan is to write an IO::CharHandle class that takes the name of a character encoding as an argument and transparently performs conversions. the goal is to work with utf8 data only inside the boundaries of the container, and convert to native encodings when data passes out of the container. Note that this is covered in Perl 5.7.2+ using the PerlIO layer. For an example see XML::SAX::PurePerl which parses XML switching encodings on the fly. -- Matt/ /||** Founder and CTO ** ** http://axkit.com/ ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** mod_perl news and resources: http://take23.org ** \\// //\\ // \\
