RE: Beagle Networking / Beagle Win32 Port


A nice, but not-that-fancy, screenshot;

Builds with cygwin, runs without it.

Done up to now: 
- Abstracted GConf into a Configuration.cs to use windows registry and
gconf where applicable.
- Use System.Management and System.Diagnostics in SystemInformation.cs
- Changed all Inotify code to use System.IO.FileSystemWatcher (started a
IFileWatcher implementation based on INotify for mono class lib, but not
finished yet)
- Use SQLite when ExtendedAttributes are not available (Jon and Joe G
was working on this I think), but there's prolly a better way to do
this... Perhaps a windows specific thing?
- Extended the NetworkInterface and added network support to Query.exe
when a DBus daemon is not found.
- Temporarily disabled stuff of no relevance (unix only queryables)

What should be done:
- Outlook/AIM/WAB & whatever queryables needed for windows
- Add a BestWindow and BestTray based on SWF.
- Port DBus to windows. (queries work now, but the RCI and DBus query
interfaces are disabled if a DBus daemon is not found.
- Port stuff I disabled like the screensaver and gecko stuff
- Make some misc stuff more generic, such as tiles (mail, imlog, blog)
- Port filters based on unix libs


On Fri, 2004-11-19 at 11:13 -0500, Nat Friedman wrote:
> [ 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
> already. 
> 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
> bad.
> > 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.
> Nat

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