Stephen Gallagher wrote:
On 10/25/2009 11:25 PM, Dmitri Pal wrote:
> See comments in the patches.
> Patch 1: Improvements to trace macro
> Patch 2: New object - dynamic array with reference count (to build it do
> it inside its directory it is not hooked to the build tree in this
patch)
> Patch 3: Minor improvement to collection
> Patch 4-6: A set of patches improving ELAPI. It is still work in
> progress and not the final state. I am just trying to slice things. View
> then as an early preview rather than something that needs to be pushed.
> Comments about those are welcome but again it is not even half baked
> work though it builds, runs, does what I want and does not have memory
> leaks.
> Next steps:
> * Revise high level API to add error callbacks
> * Add sync and async variant of the IPA
> * Hook tevent for sync API
> * Internally enforce that the dispatcher is always async, i.e provide
> you own event loop in non advanced function
> * Revise sink <-> provider interface . Assume all sinks are async.
> * Wrap internal processing of the events on the sink level in such a way
> that the event travels between the sinks via event loop calls and
> callbacks
> * Update wiki with design changes
> * Develop man pages
> These are significant changes that affect the code so I am reluctant to
> pass it over to anybody at this point.
> Plan to do as much as possible as soon as possible...
> _______________________________________________
> sssd-devel mailing list
> sssd-devel(a)lists.fedorahosted.org
>
https://fedorahosted.org/mailman/listinfo/sssd-devel
Patch 0001: I can't figure out why you're restricting the length of the
filename and line number in the trace macro. What's the rationale for
this? I think it's fine to leave this as '%s (%d)' rather than '%40s
(%4d)'. Otherwise, this patch looks fine.
First of all it was this way from the very beginning . I mean I used the
special size modifiers.
Main reason is that then the trace is nicely aligned in columns and
easier to read.
Patch 0002: There is no reason for ref_array_next() and ref_array_prev()
to exist, as far as I can tell. Functionally, they're identical to
calling ref_array_get(ra, idx+/-1, &acptr). It would be different if you
were providing an iterator for the array.
This is convenience and I like these two
interfaces because they provide
what I need.
The iterator will be too much overhead for now.
For this structure to be more useful, it should also have the ability to
delete elements from the array (maybe just the end, since this is
essentially a deque) and shrink the array.
Yes but I will not do it until it is required.
Currently this functionality is left for future.
I have not created this interface to be 100% independent at least for now.
Currently it is a helper and doe not need to act as a full blown API.
As I started using it I see the needs for other features. If it will
become an API on its own is yet to be seen.
It is good enough for the purpose and I do not have time to add more
functionality to it.
Patch 0003: Please update the comment in collection.h to denote that
passing NULL means to get a reference to the current collection.
Will do.
_______________________________________________
sssd-devel mailing list
sssd-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/sssd-devel
--
Thank you,
Dmitri Pal
Engineering Manager IPA project,
Red Hat Inc.
-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/