[Fwd: Re: Status update]

[Harish Krishnaswamy <hk...@comcast.net>]

It is annoying that the reply-to does not go to the list ...

-------- Original Message --------
Subject: 	Re: Status update
Date: 	Thu, 15 Apr 2004 10:27:29 -0400
From: 	Harish Krishnaswamy <hk...@comcast.net>
To: 	Christian Essl <ch...@yahoo.de>
References: 	<00...@ALMIGHTYBEAST> 
<40...@comcast.net> <op...@mail.yahoo.de>



Honestly, I am not concerned about the possibility of making the module 
descriptors intentionally complex but rather the ability to make it 
simpler ;)

-Harish

Christian Essl wrote:

> I'm biased towards scripting. On one side it is impressive how fast 
> and what you can do with it on the other hand scripts can turn out to 
> be monsters quite soon. Hivemind in it's current static way makes 
> things just easy - most important to read the source, but I guess also 
> for tools.
>
> I agree that compile-time or classloading-time aop frameworks are 
> orthogonal to HiveMind. But in terms of intercepting proxies 
> frameworks like dynaop are way ahead of what we have at the moment. 
> Maybe a decorating service-factory which applies dynaop to a 
> service-impl would help. Exlplicit interceptors are given as 
> parameters drafted-in interceptors are specified in a config-point. 
> The factory could be in the lib module and therefore add no further 
> dependencies to the core. Such an explicit factory aproach would also 
> prevent some nasty circularity problems with drafted-in interceptors.
>
> I guess this would also be quite easy to implement when there are 
> recursive-schemas or a way to specify that elements can be gotten 
> under a certain schema-element.
>
>
> On Thu, 15 Apr 2004 00:16:41 -0400, Harish Krishnaswamy 
> <hk...@comcast.net> wrote:
>
>>
>>
>> Howard M. Lewis Ship wrote:
>>
>>> Please elaborate on some of these ideas.
>>>
>>> I really, really, really don't want to sacrifice HiveDoc.  I think 
>>> applications will be using dozens
>>> if not hundreds of configurations, services and contributions and 
>>> without HiveDoc there will be no
>>> way to make sense of it all.
>>>
>> I would absolutely not want to lose the hivedoc myself. I am simply 
>> suggesting producing the hivedoc from the script module descriptors. 
>> With scripting languages, you can document the descriptors in javadoc 
>> format and access them from the AST. And then its simply a matter 
>> spitting it out in the form of xml/html and formatting them for 
>> display. This can be further simplified with Groovy 'cause it has 
>> native support for markups!
>>
>>> AOP as in AspectJ is, I believe, orthogonal to HiveMind.  What kinds 
>>> of introductions do you want?
>>>
>> I would like to see simple mixin type introductions. For eg., with 
>> the simple event producer/listener pattern I have to pollute my 
>> classes with event handling code which can be avoided by isolating 
>> this code and mixing it in as needed. May be this is orthogonal to 
>> HiveMind. May be we just need a hook to allow dynamic weaving of 
>> services by proxy based aop frameworks like dynaop.
>>
>>> Perhaps we need a more sophisticated way of defining the 
>>> interceptors for a service; a mix of
>>> *explicitly* contributed interceptors and some other system where 
>>> interceptors are "drafted in" via
>>> some other form of configuration.  Regexp is a good idea ... though 
>>> that ties us to ORO or JDK 1.4.
>>>
>> Yes, it introduces a dependency but I think it is justified in this 
>> case. On a related note, I kinda like jakarta regexp package better 
>> than oro. regexp is very compact and seems as performant as its 
>> couterpart.
>>
>> -Harish
>>
>>> -- 
>>> Howard M. Lewis Ship
>>> Independent J2EE / Open-Source Java Consultant
>>> Creator, Tapestry: Java Web Components Creator, HiveMind
>>> http://howardlewisship.com
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: Harish Krishnaswamy [mailto:hkrishnaswamy@comcast.net] Sent: 
>>>> Wednesday, April 14, 2004 8:00 PM
>>>> To: hivemind-dev@jakarta.apache.org
>>>> Subject: Re: Status update
>>>>
>>>>
>>>> 1. I want easier and more AOP! I think the interceptor-set idea is 
>>>> good but we need a way of applying these sets to services in one 
>>>> fell swoop using regexp or something. And we need atleast some 
>>>> simple introductions.
>>>> 2. Secondly, I want easier and more powerful configuration with 
>>>> scripting especially with Howard's recent ideas on the wiki. I had 
>>>> second thoughts on this before due to the line-precise error 
>>>> reporting and hivedoc that comes with the current xml descriptors, 
>>>> but having done some research it turns out that the scripting 
>>>> languages provide a complete AST that simplifies things a whole 
>>>> lot. Really, all the complexity in HiveMind is simply due to the 
>>>> xml descriptors. I haven't yet had a chance to take a look at 
>>>> plugging this into Hivemind. I am guessing it should be simple.
>>>>
>>>> -Harish
>>>>
>>>> PS. Why don't the messages here not have the reply-to attribute set?
>>>>
>>>> Howard M. Lewis Ship wrote:
>>>>
>>>>
>>>>> So ... what are people doing with HiveMind?  It's back, it's
>>>>
>>>> free and I've been doing some work on
>>>>
>>>>> it. I've also been doing some planning for HiveMind on the Wiki.
>>>>>
>>>>> I'm afraid that all the interruptions caused by the IP
>>>>
>>>> problem, and then by the infrastructure
>>>>
>>>>> delay, have hurt HiveMind. The community is failing to
>>>>
>>>> coalesce at the new home ... it's important
>>>>
>>>>> that the other HiveMind users and developers check in and
>>>>
>>>> start communicating about their needs.
>>>>
>>>>> I have plans for HiveMind in the immediate future:
>>>>> - Hook into J2EE for declarative security on services via an
>>>>
>>>> interceptor
>>>>
>>>>> - Create a gateway into Spring, to allow managed Spring
>>>>
>>>> beans to appear as HiveMind services
>>>>
>>>>> - Interface with JMX: map JMX MBean interfaces to HiveMind
>>>>
>>>> services, and add a "performance"
>>>>
>>>>> interceptor that records method invocation data into other JMX beans
>>>>> - Transaction interceptor
>>>>>
>>>>> That's my immediate list ... what's your?
>>>>>
>>>>> -- 
>>>>> Howard M. Lewis Ship
>>>>> Independent J2EE / Open-Source Java Consultant
>>>>> Creator, Tapestry: Java Web Components Creator, HiveMind
>>>>> http://howardlewisship.com
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
>>>>> For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
>>>> For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
>
>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org