directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pierre-Arnaud Marcelot" ...@marcelot.net>
Subject Re:
Date Mon, 04 Dec 2006 15:52:53 GMT
Hello Stefan,

My week-end in Porto was wonderful.
We had a nice weather and I took some good pictures (especially some very
wide panoramic shots that are gorgeous).

I saw you started working this week-end on Apache DS and LDAP Studio
reporting some bugs and filling some Jiras.

We should discuss this directly on the Dev List, so that other developers
can follow us. I'm forwarding this answer to the Dev List.

I tried to add the ELBE-plugins as-is into LDAP studio (LS) and it works
> fine
> with some exceptions:
> - Standard menus and keybindings reused from Eclispe are not available


True... We'll have to add all the standard "File" & "Edit" Menu in the LDAP
Studio RCP App, as well as the associated key bindings.
I'll fill a Jira for that.

- New created LDIF files can't be saved


I think this is due to the previous issue... Once we have all the standard
menus and key bindings it should be working. What do you think ?

- There is a problem with the antlr.jar. When LS starts with the ELBE
>   perspective, then the views in schema editor perspective are not
> available.
> Also when adding the LS-plugins into eclipse works fine. The antlr problem
> also
> exists there.


I'll fill a Jira and start to investigate on that.


> Some words about the architecture of elbe-core:
> -----------------------------------------------
> - JNDI is used to connect to server, but all JNDI stuff is encapsulated in
>   4 classes in a so-called ConnectionProvider.
> - A Connection object is a central object for accessing the directory. It
>   provides search and modify operations and caches entries.
> - Any interaction with the remote directory is done asychronly using the
>   Eclipse Job-API. (package net.sf.elbe.core.jobs)
> - A search works as follows:
>   1.) Create a Search/SearchParameter object.
>   2.) Create a SearchJob and execute it
>   3.) Job calls Connection.search()->ConnctionSearchHandler.search()->
>       ConnectionProvider.search()
>   4.) Search results are returned as Enumeration of LDIF records, so in
> the
>       ConnectionProvider JNDI objects are transformed to LDIF
>   5.) In ConnectionSearchHandler the LDIF records are transformed to the
>       internal Entry/Attribute/Value model.
>   6.) When search is finished the SearchJob fires an event.
> - A modify works as follows:
>   1.) Get/create your modification objects (Entry/Attribute/Value)
>   2.) Create a <Modify>Job, e.g. a ModifyValueJob and execute it.
>   3.) Job calls Connection.modify()->ConnectionModifyHandler.modify()
>   4.) The ConnectionModifyHandler converts all model objects to LDIF
> modify
>       operations and calls ConnectionProvider.appplyModification()
>   5.) The ConnectionProvider converts the LDIF to JNDI calls.
>   6.) When modification is finished the Job fires an event.
> - The usage of LDIF as interface between Controller and I/O makes it easy
> to
>   log modify operations and to perform LDIF import/export.
> - Event handling: Views don't register at each object, but register at the
>   EventRegistry for specifc events (e.g. EntryModificationEvent). On model
>   modification the events are fired using the EventRegistry. When
> executing a
>   job, e.g. reading attributes from LDAP, the job suspends event-fireing
> in
>   its thread. When finished the job resumes event-fireing and fires one
>   consolidated event.


Thanks. This is now clearer how the core works. This is a great architecture
that we should adopt in LDAP Studio.

Discussion:
> -----------
> We should discuss how to merge our tools. Here are some issues we could
> discuss,
> I brainstormed a bit:
>
> 1.)
> I created ELBE primary as Eclipse plugin whereas LS is designed as
> RCP-App.
> For a eclipse plugin IMO it is important that it doesn't add too much
> menus and icons to keep the UI clear. That is the reason why the entry
> editor and the search result editor are are singeltons, to avoid wasting
> the editor area. Perhaps we could create a separate plugin that adds all
> the menus and icons for the RCP-App but not for the plugin. Additional we
> could provide separate distributions for users, admins and ADS-developers.
>


Yes it could make sense, but since the menu is hidden when the LDAP
Perspective isn't the frontmost perspective, I think the menu isn't a really
big issue. Regarding the singleton entry editor and search result editor,
several distributions could be a solution. We have to think about that.

2.)
> Do you want to continue development on your browser plugin? It seems that
> it is not as powerful as ELBE. On the other hand the ELBE code could
> receive some refactorings.


No, LDAP Studio Browser Plugin is at early stage of development and ELBE is
much more functional and has a lot more features. I'm now focusing on
integrating gradually some of ELBE features into LDAP Studio.

3.)
> It seems we have two similar approaches to access the directory: we use a
> pivot format (LDIF vs. DSMLv2). Till now the LDIF was sufficient for me
> and
> it is quite easy to log modifications. But I think the DSML is more
> powerful,
> I think it makes sense to switch to DSML and to use your DSML-Engine.


I agree. DSML is more powerful than LDIF. I still have some issues with the
DSML parser, especially with base64 encoding but we can handle that easily I
think. We may also need to adapt and open a little bit the DSML-Engine API.

4.)
> Both ELBE and ADS have a LDIF parser and model. The LDIF parser in ADS is
> good for import/export. But in ELBE I use the model also for the LDIF
> editor
> and therefor I need a more powerful model.


I see. It could be great to provide a LDIF editor to LDAP Studio using the
shared-ldap (which contains all LDIF related utilities).
I'm also planning on adding a DSML editor to complete the set of editors.
This way, we will be able to edit LDIF, DSML and Schema Files.
We could also work on a visual editor for LDIF and DSML.

5.)
> As I have seen that ldap-shared contains a Schema parser and model.
> Perhaps we
> could replace the  ELBE schema stuff with ldap-shared.


Yes it could be great to do that.

6.)
> Is there a plan to migrate the build environment to maven or would we keep
> ant?


I already tried to migrate to maven a few weeks ago and I got some issues
regarding the internal Eclipse computed dependencies (that are necessary to
build and run tests on plugins but should not be exported in the plugin
itself since those dependencies will be supplied by the Eclipse platform or
the RCP app). Have you ever successfully build an Eclipse plugin using Maven
?


> 7.)
> Is there a plan to provide a online schema editing?


Indeed, in ADS we plan to be able to modify a schema within the server but
this isn't a trivial thing since we have to modify then the already existing
entries affected by the schema changes.

8.)
> In ELBE-UI all texts are in source code :-(. We should externalize the
> strings.
>

Yes, although I think some LDAP Studio projects also have UI Strings
directly in source code. An effort should be made in this direction.

I think we have to talk on IM to compare and share our vision on the LDAP
Browser Plugin. It may be a good thing to write down some specification
together and a timeline for LDAP Studio LDAP Browser Plugin.

See you.

Pierre-Arnaud

Mime
View raw message