On Mon, 2008-01-21 at 22:26 +0000, John Carr wrote: > Hi Owen > > > There are two basic reasons why server side extension is hard: one is > > simply that to do any hacking on the server side requires getting a test > > instance of the server going, and that's a quite a project. The other is > > that the emphasis for the data model has been exporting the existing > > server objects via the data model, so you need to know how we implement > > "existing server objects" and add a new one. And that's no simple > > thing, since it adding little bits of code scattered throughout > > lots of different directories. > > How about rolling a VM image like the GDK that Ken VanDine has been > working on. Of course i'm assuming everything is free and open source, > with no horrible licensing issues that would prevent packaging... > Which may be foolish of me :-) It's not a bad idea. - To make a complete VM, we'd need to port from the Sun JDK to IcedTea, though would could tell people to install the JDK on top of an otherwise complete image. - You'd need to give the VM at least 1G, possibly more. The combination of Eclipse (for editing) with JBoss (runtime environment) is pretty heavy. So you'd need a pretty heft box to use it. - There can be some performance problems with running Eclipse inside a VM, though perhaps more when Windows is the host OS than with Linux as the host OS. > In terms of an existing object, why not disect and document the GConf > implementation? We could write a tutorial about how to add new objects, easily enough. My concern is that it would be: "Add some code over here" "Add some code over here" "And add some code over here" But without more context, knowing why the code was being added, how to extend it, and how to debug problems doesn't necessarily follow. Still, we should make a stab at it. > > So, how to fix this and make it easy for people to implement their own > > applications with an online component, without becoming experts in a > > complicated Java server? One approach is to punt and say that that the > > data model isn't involved for applications. After all, we need to work > > with external non-GNOME web applications. People should just implement > > server components as a normal web app. And the simplest version of this > > is to use an existing application. I think the suggestion of basing a > > TODO list on rememberthemilk.com is a good one. > > I don't like this approach for the simple reason that it sucks at > pushing back to me. I have to have a timed "wake up and scrape an API" > thing going on. Yucky. > > > Alternatively, we could create some sort of "simple data storage API" > > that maybe wouldn't allow all the features described above, but would > > work fine for a basic TODO list. > > Thats what i'd had in mind with the simple object i mentioned in an > earlier post... > > > In fact we already have this (!); if > > you just store your TODO list items in GConf and add a line to: > > > > online-desktop/online-prefs-sync/online-prefs-sync.synclist > > > > (Or install a sync file for your application), then the TODO list items > > will automatically be propagated between all of your desktops. The > > downside is that conflict resolution is very simple to non-existent, so > > it's not going to handle offline TODO list editing on multiple machines > > well. > > What if i want to sync data from an existing application? With Conduit > I could sync from Evolution and Tomboy in to online desktop via fake > GConf keys. But they wouldnt be real GConf keys and i dont want them > in my gconf as well as in evolution/tomboy... (Note that we could do > this by converting contacts to actual gconf keys, or by pretending to > be gconf when talking to online desktop - i prefer there to be no > middle man) > > In this scenario, the Conduit always up to date stuff would work with > Tomboy (and Evo too with a bit of love on the python bindings front).. > so as you update your tomboy tasks they are pushed to online desktop > which can push them to other things looking at the generic object > type.. Conduit on other machines could pick up notifications and > update their Tomboys and Evolutions. Conduit has conflict resolution > too... > > I would push for having an even more generic object type than trying > to squeeze contacts and event data into gconf keys though. > > > But there is months of work there, so it's not going to happen quickly. > > For right now I think rememberthemilk or maybe the GConf approach is the > > right one. > > Like i said before, Conduit will likely sync to rememberthemilk > anyway. And hiveminder. And any other website our users might care > for. As I understood it, the original question from Govind wasn't related to Conduit. Similarly the GConf approach wasn't a suggestion for Conduit, but for creating online-synced TODO list with minimal work. As I said, it won't handle simultaneous edits from multiple locations very well. > I'm definitely interested in pushing data at online desktop > though, but hope you can be swayed to add a more generic object type > of (uid, lastModified, type, blob) - the type allowing me to ask for > just one type of blobs e.g. contacts, tomboy etc and the lastModified > allowing us to ask for a list of all contacts and work out "x was > added, y was modified and z was deleted. > Notifications can then be > used to sync the local client until the current session ends... Hmm, converting that to data model terms on the server, that probably means something like: @DMProperty List<BlobDMO> getBlobs(); In BlobDMO: @DMProperty(defaultInclude=true) String getType(); @DMProperty(defaultInclude=true) long getLastModified(); @DMProperty String getData(); Note that type/lastModified are defaultInclude but not the data, so requesting "blobs +" from the user's resource would let you track the full set of (resourceId,type,lastModified) pairs on the client and could go and get the data for any blob resource where you needed that. And "update methods" http://online.gnome.org/p/blobs#addBlob (String type, String data); http://online.gnome.org/p/blobs#modifyBlob (String resourceId, String type, String data); http://online.gnome.org/p/blobs#deleteBlob (String resourceId); My comments: - We have a small limit to the size of objects we can store into the database (pending upgrading our server to MySQL 5) that would mean that we'd need to use a look-aside file store for the blob contents. That's simple enough to do, however. (And might well make sense in any case.) - To make the addBlob call return the resourceId requires some minor extensions to the data model (a few hours of work, would be useful for other things as well.) - At the point of something like the above, would it be better to just export a DAV share per user? We actually have a bunch of DAV code in the server, though I'm not able to tell you what it actually does at the moment. A set of per-user opaque blobs doesn't really take advantage of the capabilities and strengths of the data model, which is designed for: - Fine grained data objects - Shared data objects - Pulling in and integrating data from external services - Owen
Attachment:
signature.asc
Description: This is a digitally signed message part