|
From: stephan b. <st...@s1...> - 2004-12-22 19:33:36
|
On Wednesday 22 December 2004 20:05, Christian Prochnow wrote:
> Place URL in Net/.
Will do.
> SQL stuff isn't ported yet and needs major
> rework. However .. i think the String class must be done before
> starting with the URL class.
Will the string support implicit conversion from (char *) or
std::string? If not, i would prefer to see URL based off of
std::string. If there's an implicit conversion, i see no problem with
basing URL off of it.
> What about support for
> internationalization in the URL class (don't remember the correct
> name)?
i know very little about i18n, so i can't say much about it.
> > - Add Request::read( string &, size_t ). Doh - Request isn't ported
> > to pclasses2 yet.
>
> We first need a Plugin library. Since Plugin loading is not a core
> component, and isn't a System abstraction class either it should go
> into it's own P library. Stephan .. how about your excellent
> class_loder stuff ? Shall i integrate it into P and drop the old
> Plugin stuff ? your code is much more elegant and cleaner.
*blush*. Actually, earlier today i was thinking about how horrible one
of the classloader's "features" is, and want to rewrite it. i like the
cllite interface a lot, though, and i get TONS of usage out of it. That
said, i will be more than happy to add a classloading layer to P. i'd
be honored, in fact, to be allowed to port my code into the tree :).
> > - Port some utility functions out of ps11n into P, like
> > iomanager_read(string url), which reads in input from any
> > IOManager-supported type.
>
> Should go into P::IO library.
Agreed. i will generally follow the policy of "put it wherever it'd deps
say it should." If new dependencies would be introduced i will first
ask for your approval.
> > - Maybe port the build tree to toc (the tools s11n uses). This
> > depends on Christian's decision.
> >
> > - Add a new shell-app module:
> > - add argv handling.
> > - add command dispatcher
> > - add eshell's argv type ('arguments').
>
> Hmm .. should this go into Util/ or shall we add a "application
> support" library ?
i think argv belongs in the Util section, and the rest as a standalone
module or plugin, but i'm not sure what the plugin abstraction might
look like yet.
> For example SimpleApp should go into "application support" lib, i
> think argv handling as well.
That'd work, too. That makes more sense, actually.
> If argv handling is "generic" and doesn't rely on input from
> "main(int, char*[])" it should go into Util/.
The argv PARSER does not strictly rely on main(), but is not much use
without it. The argv TYPE is 100% independent. The argv TYPE is simpy a
sequence container of args with some features to ease it's use as an
argc/argv replacements. The features like $var/alias expansion depend
on the app layer (Environment and Aliases objects), so the argv list
probably belongs there as well.
That's a long way of saying: the ArgvParser class belongs in util, the
Arguments (Argv?) class belongs in the app utils.
> Seems that this Christmas becomes a funny hacking session ...
That's how i usually spend them. :)
--
----- st...@s1... http://s11n.net
"...pleasure is a grace and is not obedient to the commands
of the will." -- Alan W. Watts
|