On Thursday 25 October 2001 13:54, Greg McCarroll wrote:
> > > > Messaging
>
> Sending a message by unknown transports to some sort of combination,
> such as the following

I think "unknown" is fairly operative here. I really like the idea of 
completely pluggable implementations. It's harder, but it's a lot more useful 
and it does contribute seriously to the development of an enterprise scale 
system: people can use what fits best the scale of their needs.

> > > > Webservices
>
>      This is may be just SOAP based services, it may be some sort of
>      screen scraper component, i really am not sure.

I think it's mostly Messaging, possibly with some security. I could have 
missed something though.

> > > > Exception and Error tracking
>
>      This is probably just a foundation standard that isn't visibile
>      at ``enterprise'' level, but is used internally in enterprise
>      style modules, so that they all output errors in a common fashion.

It will probably be visible to anyone that programs using P5EE. Perl's 
exception handling has got itself a bad name (in some case for good reasons, 
though the people that give it a bad name often ignore the said reasons) and 
I think it's really important to get it right.

> > > > Workflow Management
>
>      Definition of workflows in some sort of graph format, presenting
>      choices of next operations depending on workflow task results.

Should this apply beyond the scope of applications ? Eg in being able to 
describe workflow between actual people.

> > > > Internationalization
>
>      Not sure about this one.

Being sure that the system is usable irrespective of language, character 
sets, etc. Also probably providing better localisation than the normal locale 
can I guess.

> > > > Documentation
>
>      =pod ? and conventions for enterprise bean/component
>      documentation standards, maybe an =isa setting?

Metadata in POD is imho very important. I think ActiveState has worked on 
this notably for Komodo and for .Net. Also providing standardized translation 
of POD into better formats would certainly help. I don't think perldoc will 
look serious to a bunch of managers. Translating to XML (sdocbook would 
probably be a good choice) and converting with XSLT to nice looking and 
cross-referenced HTML would be a must (hence one of the needs for metadata).

> > >   XML
>
>      See JAXP

And more than just JAXP/PAXP, XML is probably going to be used in many places 
in the framework.

>       Object Persistence
>
>       storing objects to somewhere/something, that can later be
>       retrieved by some sort of ID

Yes, that's very important.

> > Definitely. In fact, I think that some frameworks will be more foundation
> > packages, on top of which others will build. Those probably need to
> > happen first.
>
> I think the above list is far too long for an initial project, we need
> to shorten it, but we don't want to implement just foundation things
> in the first run. The higher level frameworks will generate
> requirements for the foundation frameworks, this is a good thing.
>
> So we need a nice set of foundation and interesting higher level ones
> in the first generation of P5EE.

I think that people ought to simply propose the APIs that they see for their 
parts, and go ahead implementing them after some discussion here (possibly 
within some sort of RFC process, though maybe not as formalized as the Perl 6 
one). Dependencies will make themselves clear in the process, and more 
discussion/code will follow (hopefully :-).

-- 
_______________________________________________________________________
Robin Berjon <[EMAIL PROTECTED]> -- CTO
k n o w s c a p e : // venture knowledge agency www.knowscape.com
-----------------------------------------------------------------------
For every complex problem, there is a solution that is simple, neat
and wrong.
-- H.L. Mencken(1880-1956)

Reply via email to