Re: [Hawkeye-devel] State of the project

[Sebastien R. <kr...@us...>]

Hi guys,


Nice to see the mailing list being used :)

I agree with you on the documentation. I plan on changing the structure of =
the=20
document itself, to make it more straightforward to read and write (instead=
=20
of the currently too formal IEEE document style): one chapter on the=20
supervisor process, one chapter on the capture process, etc... each devided=
=20
into sections and subsections about specific points on each part of hawKeye.
Then it will be easier for everybody to write a bit of documentation on wha=
t=20
they have developed.

About your part Sandeep (implementation of a man-in-the-middle against SSL)=
: I=20
would prefer to have a stable capture process before integrating even more=
=20
complex code, and for the capture process to be finished (Laurent Decool an=
d=20
me have to finish respectively the remote capture and the loading of offlin=
e=20
capture files) I first need to finish the change of Inter-Process=20
Communications in hawKeye, on which I have been working the whole week-end:=
=20
you might have noticed new files on the repository called ipc.pl and ipc.xm=
l,=20
which generate ipc.c and ipc.h files in various directories for IPC clients=
=20
and servers in hawKeye, RPC-style... Anyway, I hope you won't have to wait=
=20
too long before we integrate your code :)

On Monday 21 November 2005 10:07, Sandeep Kohli wrote:
> Hi
> I completely agree with Rajendra.
> And sebastien has promised me that one weekend when he's free he's going =
to
> eXplain me how to incorporate my module into the system. :P ;)
> Maybe then, I can write a doc on how the system works and you all can
> update the details about your own individual modules.
> What say u?
>
> sandeep
>
> On 11/21/05, Rajendra Stalekar <rst...@ya...> wrote:
> > Hi everybody,
> > Just a suggestion, we must all understand the design
> > of the product from the existing design document,
> > also we must have our thing incorporated in it.
> > Otherwise we will probably only know our modules and
> > won't know the product as whole. That's what I find
> > from experience. Well it's just that we must know how
> > it works.
> > So let's say if there are bugs and someone from that
> > module is not available , anyone of us must be easily
> > adapt to that and fix it.
> > Thanks a lot Seb for co-ordinating this,inspite of his
> > hectic schedule:)

=2D-=20
S=E9bastien Raveau (aka Kryczek)