[mina] Refactoring MINA IoFilterChain (Was: IoFilters: DIRMINA-121 / 122)

[Stephen J. McConnell]

 
> How about a little poll:

 [x] +1 MINA should become its own TLP at Apache [ ] +0/0/-0  
     Maybe later, or let's get a separate mailing list for now etc.
 [ ] -1 MINA should remain at Directory as is

Steve.

http://www.dpml.net

[JAMES Nightly Build System]

Trustin,

> MINA is just a network application framework for now,
> but I don't think it will be forever.

> * Unified administrative view based on JMX and web that all MINA
> application will get administrative benifit from

Might want to combine with OSGi.

> * High-performance server implementations (both standalone and
> embedded) for popular protocols based on MINA

JAMES may use MINA, but that doesn't mean that JAMES will be a MINA project.
DNS, CIFS, etc., are in the Directory Project.

MINA should have its own list for now, and eventually (but not yet) look at
TLP status, or become part of an OSGi TLP (only if that merger made sense).

        --- Noel

[Trustin Lee]

Noel,

2005/11/17, Noel J. Bergman <noel@...>:

JAMES may use MINA, but that doesn't mean that JAMES will be a MINA project.
DNS, CIFS, etc., are in the Directory Project.

Of course.  What I want to provide is mainly a protocol provider which can be extended to a stand alone server or to an embedded server.  This means there can be more than one implementations from the same protocol codec.

Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/

[Vinod Panicker]

Hey Alex,

What was the result of the poll?  I think most of us had agreed on a
separate list atleast.

Regards,
Vinod.

> Alex Karasulu wrote:
>
> > Looks like the traffic is picking up on MINA and things are heating up
> > as we approach 1.0.  Initially my thought was to get a separate list
> > for MINA however I'm thinking it might be best to just see if we can
> > promote MINA to a TLP.  It has out grown its place in directory and
> > many projects will depend on it.  It makes sense to me to see it
> > acquire a life of its own.
> >
> > There's a good sized community brewing around MINA.  I'd like to see
> > more people come forth as committers then see if we can get a proposal
> > before the ASF board on budding off the MINA project.  IMHO this is
> > better than creating a separate mailing list.
> >
> > Right now it would be good to see who favorrs this?  Any comments or
> > for or against this idea?
> >
> > How about a little poll:
> >
> > [ ] +1 MINA should become its own TLP at Apache
> > [ ] +0/0/-0 Maybe later, or let's get a separate mailing list for now
> > etc.
> > [ ] -1 MINA should remain at Directory as is
> >
> > Alex

[Alex Karasulu-4]

Vinod Panicker wrote:

>Hey Alex,
>
>What was the result of the poll?  I think most of us had agreed on a
>separate list atleast.
>
Let me ping infra on this in a bit. Might be up right after the new
year.  Coolio?

Alex

[Chris Betts]

Hey Alex,

     to the great astonishment of all concerned, it looks like CA is  
actually ready to finally commit to donating JXplorer.  Hoo-effing-
ray.  I just hope you guys are still interested.

     A couple 'o things - first, if they do donate JX it should make  
the web based client a lot easier as well; the version I've done up  
shares code with JX it would have been a pain to redo.

     Secondly, I don't know who is talking to whom between CA and JX,  
but the guy on the ground here in Oz managing the deal is my old mate  
Tim Bentley, who is 100% solid - he's an old, old friend of mine from  
Uni days and is a hands on developer type with a good grounding in  
open source and Apache.  Knowing CA they'll probably try to run the  
whole show out of the states (maybe with a chap called Venkat  
Reddy?), but if there's anything we can do locally just let us know.

     Thirdly, I suspect there's a lot of overlap in code between  
Apache DS and JX, and JX also manually does stuff that is now in  
basic java (e.g. when JX was written there was no 'LdapName' class,  
so it has it's own version).  I don't know how much effort we'll want  
to go to to synch the two... there's LDIF code and all sorts of jazz  
in JX which I think you guys have also written.  *shrug* - we'll  
figure it out.

     Anyway, fantastic to see things moving again, although I'll  
believe it's all a done deal when everyone has signed on the dotted  
line :-).

         Chris

-------------------------------
Dr Christopher Betts
Pegacat Software
Melbourne, Australia
chris@...
[phone]

[Chris Betts]

<ahem>

Must not email when tired.  Apologies for posting a personal message  
to Alex to the entire list.

[Emmanuel Lecharny-3]

Hi !

For such a good news, we are quite happy that you were tired yesturday ;)

On 5/17/06, Chris Betts <chris@...> wrote:
> <ahem>
>
> Must not email when tired.  Apologies for posting a personal message
> to Alex to the entire list.
>


--
Cordialement,
Emmanuel Lécharny

[JAMES Nightly Build System]

> Apologies for posting a personal message to Alex to the entire list.

No worries, Mate.  Besides, that message *belonged* on the list.  :-)
Looking forward to hearing from CA.

        --- Noel

[Emmanuel Lecharny-3]

Hi all !

I'm currently implementing all the Ldif import operation, and I need
your light.

Question : are ModDN and ModRDN synomymous? It seems so, and those two
names are just there for historic reasons. And there is only one request
ModifyDN, no ModifyRDN. So what do you think ? Any clue ?

Thanks a lot !

Emmanuel

[Norval Hope]

Hi,

All the evidence I could find seemed to suggest they are indeed
synonyms. The difference between ModDN/ModRDN really comes down to the
presence (or otherwise) of the "newsuperior" attribute rather then the
value chosen for the "changetype" attribute.

I found this http://www.novell.com/documentation/ndsedir86/index.html?page=/documentation/ndsedir86/taoenu/data/a6i0f1p.html
 section "Table 143. Modify DN Change Type Fields" to be a good
summary of related attributes (but don't have time to cross reference
this with relevant RFCs etc).