At 08:22 PM 11/22/2001, brian moseley wrote:
>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.
While this is possible, I think that if the objects have a configuration
method that the factory object passed config information to, the API itself
can usually remain fairly consistent.
Also have a factory doesn't mean that all the concrete implementations have
to only use that API. Like an abstract/concrete class structure, the
concrete classes should be allowed to have their own methods specific to a
certain circumstance if necessary.
>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).
Yes. It depends on the subsystem.
>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.
I think I would really like to see this.
> - 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).
I think a common way of passing config information around P5EE is extremely
useful. But I don't think it's necessary either. Different types of configs
are good for different situations.
> - 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.
We should be careful. Logging is different from Tracing. To me tracing is
just about system and app debugging . But logging also encompasses
application layer logging.
> - serialization: again, a bit of infrastructure that i
>hadn't thought of but which is absolutely necessary.
How necessary is this? Can this be a matter of just choosing Data::Dumper
or some other data structure serialization? Or are you referring to need
like adding a construct to allow a serializer to know whether to do deep or
shallow copies and whether a given attribute is a transient one (eg a socket).
__________________________________________________
Gunther Birznieks ([EMAIL PROTECTED])
eXtropia - The Open Web Technology Company
http://www.eXtropia.com/
