RE: Beagle Networking / Beagle Win32 Port

[ Cc'ing the list on this discussion. ]

Hi Joerg,

On Fri, 2004-11-19 at 11:52 +0100, Battermann, Joerg wrote:

> by browsing through the beagle sources, I think dbus is used on more
> places than the network implementation. 

Yes.  Beagle uses a client/server architecture: the indexing and query
engine runs on a dedicated daemon, and any process can open a query and
get results remotely from this daemon. The IPC mechanism that we use
today is D-BUS. This means that we don't force application authors to
link their applications against the entire Beagle infrastructure;
instead they can just link against a lightweight IPC client.

So D-BUS is pretty fundamental to the way Beagle works right now.

We use D-BUS because it seems to be the popular thing to do in the Linux
Desktop world today, and because it is a fairly simple IPC mechanism. We
could equally have used web services or a hand-rolled system, but as
long as everyone is moving toward D-BUS, it seemed like a sane decision.

If this D-BUS momentum does indeed continue to build, then I think the
desire for a Windows port will go also.

In general terms, we are VERY open to the idea of porting Beagle to
Windows, and would entertain patches to that end.

Speaking specifically of D-BUS, Jon looked into porting it to Windows
and spoke to Havoc about the idea already. He learned that D-BUS already
has a fairly well-abstracted system layer and porting it to a new
operating system is essentially a matter of writing one file.

> So is inotify. 

inotify is, in some ways, an imitation of the intent of the Windows
ChangeNotify system. So there is an analogous mechanism under Windows

I think the right approach here would be to extend Mono's
FileSystemWatcher class to do the following:

On Linux

        - If inotify exists, use inotify.
        - Else, if Fam exists, use that.
        - Else, either poll or do nothing at the user's option.
On Windows

        - Use ChangeNotify.
Then we would simply be able to use FileSystemWatcher from anywhere and
it would work. 

> Beagle basically
> relies on those so we either write a wrapper around beagle for windows
> or get rid of these dependencies by implenting other solutions, which
> would most likely result in branching/patching-hell to stay up to date
> with the beagle main source-tree.

I think if you do it right, like I described above, it wouldn't be so

> I'll dig a bit deeper into the beagle sources this weekend, and see what
> I can up with before giving any definite statements.

Excellent. Good luck.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]