On Thu, 22 Nov 2001, Stephen Adkins wrote:
> I have done a lot of work over the last few days putting
> together a major new architectural framework proposal.
thanks for doing this. i hope it helps stimulate our
creative juices :)
i guess the heart of your proposal is the idea of the
context from which components are obtained that each present
a very simple high level interface (facade?) to a particular
subsystem.
i don't see what the advantage is in using a factory object
in this way. each application will likely need to interact
with the various subsystem apis in very different ways. i
really only see this construct being useful in simple
applications.
furthermore, i don't think many (or any) of the subsystem
apis are going to be so simple as to be provided by a single
object (component).
i do think you have highlighted a few important
architectural considerations that need to be resolved before
we start designing the higher layer subsystem apis. below
are some comments and rough ideas for the ones that i think
are most important. i propose that we hammer these out
before moving on to the higher layer apis.
- component: this seems like the beginning of an object
base class. i wouldn't mind seeing such a thing, as it could
provide standard object utility and lifecycle methods (new,
init, start, stop, recycle, destroy/DESTROY, equals and
to_string spring to mind) that p5ee apis could count on.
- config: i had not considered previously considered a
config api, as i think applications tend to use config
information internally in application-specific ways. in
wombat, i probably wouldn't use this api internally, as i
have a different mechanism that directly creates internal
objects, obviating the need for your suggested
hashes-of-hashes data structure. however, i would certainly
consider using it (or whatever it turns into) in the servlet
api for classes that provide config info to servlet
application developers. the higher layer apis will very
likely benefit from using a single config api for their
public configuration (much like many of the java apis make
it easy to configure them via properties files).
- debugging: this one is hard, and i still haven't figured
out a really great general purpose way to handle it. ideally
the amount of debugging/trace output should be able to be
specified differently for each api or component.
furthermore, debugging should be removable/compilable
out/whatever for production mode. finally, there should be
some way of outputting human readable representations of
object attributes - maybe we just count on a to_string
method existing for each object in each api, or maybe our
debugging api includes a dump_object method.
- exceptions: i heartily agree with using Exception::Class
for exceptions, altho i submit the following suggestions:
1) it should be possible to decide whether or not the
stack trace will be generated at the time the exception is
created/thrown
2) we should create a standard hierarchy of common
exceptions - IOException, IllegalArgumentException,
IllegalStateException, IndexOutOfBoundsException,
UndefReferenceException (hee), LifecycleException, etc. most
of these are probably useful outside p5ee as well.
3) all apis guarantee that to the best of their ability,
only exception objects are thrown, so that consumers of the
apis don't have to defensively code with "if ($@ && ref $@
&& $@->isa('Exception::Class::Base'))" or whatever.
- logging: all higher level apis need to take logging into
exception. they absolutely should not use warn, and they
should allow api consumers to specify a log channel to which
the api internals direct all log msgs. furthermore, the
logging api should allow apis to log at various severity
levels and to register some kind of identity with the logger
so that log messages can be matched to specific api
components.
- serialization: again, a bit of infrastructure that i
hadn't thought of but which is absolutely necessary.
