|
Home > Archive > Apache Directory Project > March 2006 > [ApacheDS] ML Update on Skype Conference Call
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
[ApacheDS] ML Update on Skype Conference Call
|
|
| Alex Karasulu 2006-01-10, 3:44 am |
| Hi all,
I'm just trying to keep the mailing list up to date with a Skype
conference call we had yesterday to discuss getting the first 1.0
release candidate out the door. We listed the items on our plate and
spoke about meeting these crazy time lines. We need all the help we can
get so please volunteer where you can.
Trustin:
---------
1) Merge LDAPS
2) Resolve all issues that is assigned to me.
3) Reorganize ApacheDS repository structure.
5) ApacheDS configuration
4) Re-org and simplify site and documentation so people can get to
answers fast.
Let's not get crazy with subproject madness. Don't confuse people
with these
subprojects all over. As far as I'm concerned we only have 3 main
projects here:
- Naming
- MINA
- Apacheds
Emmanuel:
-------------
1) test Twix intensively
2) update wiki about IDE
3) test VSLdap
4) Cleanup and fix logging making it consistent through out ApacheDS.
- log messages need to be consistent
- System.out lines have got to go
- when and how do we use DEBUG, INFO, WARN, ERROR?
- we're under jdk1.4 compatibility so we cannot use the nice slf4j vararg
means to insert values into strings so we have to make sure we have the
proper guards in place to check if debug, info or warn are enabled.
[6:46:37 PM] Alex Karasulu says: Let's get Mr. Logging Ceki to advise us.
Alex:
------
1). Finish referral support (ManageDsaIT Control)
2). Add Subentries Control
3). Implement Notice of Disconnect
4). Kick Apacheds as hard as we can with
- session concurrency
- request concurrency
- size and nature of data
- comparative smoke tests
[7:14:23 PM] Lecharny says: ldap performance paper :
[7:14:25 PM] Lecharny says:
http://www.cse.buffalo.edu/~xwang8/..._sigmetrics.pdf
5). Clean out and Re org JIRA
- DIRNAMING
- DIRMINA
- DIRAPACHEDS
- no more messing around with all these darn projects and their
subprojects
which confuses users ... no time to play SIM City (project manager
edition)
6). Compile a list of all supported RFCs, drafts and features
[7:23:04 PM] Alex Karasulu says: load, dump, recovery, data migration
tool is mandatory before 1.0 final release
[7:23:07 PM] Alex Karasulu says: Oh boy we need more volunteers  .
Alex
| |
| John E. Conlon 2006-01-13, 8:47 pm |
| Hi,
Haven't seen OSGi mentioned. Will it make it into the 1.0 RC?
John
On Tue, 2006-01-10 at 02:27, Alex Karasulu wrote:
> Hi all,
>
> I'm just trying to keep the mailing list up to date with a Skype
> conference call we had yesterday to discuss getting the first 1.0
> release candidate out the door. We listed the items on our plate and
> spoke about meeting these crazy time lines. We need all the help we can
> get so please volunteer where you can.
>
> Trustin:
> ---------
> 1) Merge LDAPS
> 2) Resolve all issues that is assigned to me.
> 3) Reorganize ApacheDS repository structure.
> 5) ApacheDS configuration
> 4) Re-org and simplify site and documentation so people can get to
> answers fast.
> Let's not get crazy with subproject madness. Don't confuse people
> with these
> subprojects all over. As far as I'm concerned we only have 3 main
> projects here:
> - Naming
> - MINA
> - Apacheds
>
> Emmanuel:
> -------------
> 1) test Twix intensively
> 2) update wiki about IDE
> 3) test VSLdap
> 4) Cleanup and fix logging making it consistent through out ApacheDS.
> - log messages need to be consistent
> - System.out lines have got to go
> - when and how do we use DEBUG, INFO, WARN, ERROR?
> - we're under jdk1.4 compatibility so we cannot use the nice slf4j vararg
> means to insert values into strings so we have to make sure we have the
> proper guards in place to check if debug, info or warn are enabled.
>
> [6:46:37 PM] Alex Karasulu says: Let's get Mr. Logging Ceki to advise us.
>
> Alex:
> ------
> 1). Finish referral support (ManageDsaIT Control)
> 2). Add Subentries Control
> 3). Implement Notice of Disconnect
> 4). Kick Apacheds as hard as we can with
> - session concurrency
> - request concurrency
> - size and nature of data
> - comparative smoke tests
> [7:14:23 PM] Lecharny says: ldap performance paper :
> [7:14:25 PM] Lecharny says:
> http://www.cse.buffalo.edu/~xwang8/..._sigmetrics.pdf
> 5). Clean out and Re org JIRA
> - DIRNAMING
> - DIRMINA
> - DIRAPACHEDS
> - no more messing around with all these darn projects and their
> subprojects
> which confuses users ... no time to play SIM City (project manager
> edition)
> 6). Compile a list of all supported RFCs, drafts and features
>
> [7:23:04 PM] Alex Karasulu says: load, dump, recovery, data migration
> tool is mandatory before 1.0 final release
> [7:23:07 PM] Alex Karasulu says: Oh boy we need more volunteers .
>
> Alex
>
>
>
| |
| Alex Karasulu 2006-01-13, 8:47 pm |
| John E. Conlon wrote:
>Hi,
>
>Haven't seen OSGi mentioned. Will it make it into the 1.0 RC?
>
>
Probably not. We only have 5 days left before a feature freeze. 1.0 RC1
is slated for Jan 15th. But the 1.1 branch will be created immediately
thereafter. So I don't think it's something to really be worried about.
Keep in mind this release is for a standalone LDAP server. Our API
libraries will not be 1.0 because we're not done stabilizing the API's.
RC1 1.0 means we freeze the features for a standalone LDAP server and
start fixing bugs in preparation for a stable 1.0.
Also we don't have enough OSGi experience on board. We welcome you to
join us in to help with the OSGi effort.
Regards,
Alex
| |
| John E. Conlon 2006-01-13, 8:47 pm |
|
On Tue, 2006-01-10 at 09:55, Alex Karasulu wrote:
> John E. Conlon wrote:
>
> Probably not. We only have 5 days left before a feature freeze. 1.0 RC1
> is slated for Jan 15th. But the 1.1 branch will be created immediately
> thereafter. So I don't think it's something to really be worried about.
No worries mate:-)
>
> Keep in mind this release is for a standalone LDAP server. Our API
> libraries will not be 1.0 because we're not done stabilizing the API's.
> RC1 1.0 means we freeze the features for a standalone LDAP server and
> start fixing bugs in preparation for a stable 1.0.
Understand.
> Also we don't have enough OSGi experience on board. We welcome you to
> join us in to help with the OSGi effort.
I am willing lend a hand to Enrique. I wait for the 1.0 RC1 and then the
1.1 branch to form first.
John
| |
| Enrique Rodriguez 2006-03-14, 5:45 pm |
| John E. Conlon wrote:
> On Tue, 2006-01-10 at 09:55, Alex Karasulu wrote:
....
>
> I am willing lend a hand to Enrique. I wait for the 1.0 RC1 and then the
> 1.1 branch to form first.
>
> John
You ready for this? The 1.1 branch has formed, so I'm preparing to
refactor it to use OSGi. I did much of this work over a year ago, so it
should be some basic refactoring and package renaming to get it to boot
again.
After that, I see 3 areas of work that need more than minor refactoring:
1) I'd like to move CM, Prefs, and UA over to Felix. This is mostly
work and discussion for the felix dev list, but these services are in
the Directory repo and we've long since discussed moving them over.
They'll need an M2 update, basic dep updates (refactoring, renaming
packages), and eventually updates to be R4-compliant.
2) Not all of the directory-backed Config Admin store was implemented;
I only did what I needed to make directory work. Basically, some
straightforward CRUD-type operations need to be quickly coded.
3) In the move to the OSGi-standard Config Admin service, some
decisions will need to be made w.r.t. transitioning the current Spring
XML configuration file. All the protocol providers I wrote (Kerberos,
NTP, DNS) work fine with Config Admin. I have Strategies in place to
use the flat XML config or to look to Config Admin.
However, the core JNDI provider and the LDAP wire protocol are not
updated to use Config Admin. Likely, the LDAP protocol provider can get
refactored to operate like the other protocols, to receive port/inet
binding and other config from Config Admin easily. This leaves the core
JNDI provider. The JNDI provider can continue to use an XML config and
we can work to DIT-back as much config as possible and leave open the
possibility of a boot props file. Although, given the presence of the
system partition, I'm not sure what can't go in the DIT.
Enrique
|
|
|
|
|