On Wed, 2004-09-22 at 20:12 +1000, Andrew Cowie wrote: > In essence, the problem is one of merging structure (the procedure to be > run) and sequence (enforcing the fact that although a hierarchical > document, it actually involves a carefully specified sequence of events, > and that order must be enforced). See [2] > > > > Are there other constraints, like the use of a specific programming > > language on the client or the server, or a specific client or server > > platform? > > No, not really (well, ok, it's not mobile devices - it's a client/server > application), > > Trying to work my way through the various option spaces so as to make > these choices has been quite the nightmare (er, "learning experience). > I've made good progress, though. > > I actually gave a presentation about this last weekend... anyone who is > interested and still reading is invited to have a look at: > http://www.operationaldynamics.com/reference/talks/WelcomeToMyNightmare/
Interesting. I note that you didn't seem to consider any high level languages :). [clarification: all the languages you considered required code/compile/execute-back-to-state/debug loops, where any change at any point requires going all the way back to the code entry point.] > [Summary: I'm working on and for Linux, in Java + gcj, writing a > GTK/Gnome app, and Berkeley DB is the back end data store. Wondering > what the heck is up with all that? Follow the link, doh! And yes, It'll > be open source] Cool. > That presentation concludes with the specific technical problem that led > me to start this thread in the first place: I am trying to decide on an > appropriate middleware technology for a problem with these aspects: > > * Relatively small groups (5-15 people, typically) so low message > volume. 2) > * Participants are distributed in space (some in the data center, some > in the office, vendor reps, contractors, and specialists may be > external) [so a solution that works reasonably well across complex > network boundaries would be useful] Which means: lightweight protocol, either trivially auditable or vanilla http/https. 3) > * Events leading to messages, however, are extremely close in time (I > check that I've done a step, you check you've done the step right next > to it, we both need updates, happens in the blink of an eye, can't loose > time from polling cycles ). which means: bidirectional protocol, and following on from 2, cannot be http. (http is not bidirectional (no one supports Upgrade properly: don't even think about it). HTTPS when used as a ssl tunnel mechanism is fairly robust, probably what you need for the corporate fw-friendliness. 4) > * Very high consequence if things get out of whack (team is updating a > mission critical system, yo!) so don't want to loose messages or history > of progress through the sequence. Updates are idempotent, though, so > receiving a message twice isn't a problem, which seems like it should > help. This is a fundamentally hard problem. (TCP for instance only notices after (IIRC) 2*MSL that a connection is down. Thats much longer than a typical poll of an http client for state. ) > Last weekend, Ben Ellis suggested to me that I consider XML-RPC. I don't > think that's the solution to my problem, but man, what a clean API [3] > > Julio's suggestion of leveraging Jabber is really intriguing. Stewart > Smith made a similar recommendation to me a few months ago, which I'd > forgotten about. So, thanks Julio! There were a lot of typically murky > complex Java APIs out there, but I found one which seems really straight > forward, [4]. If I go down this road, could either build the server as > an independent Jabber client, or hook it into a Jabber daemon as a > Jabber component. Not sure the pros/cons of that yet... As a message passing protocol, I've heard good things about Jabber, it should also pass the ssl protocol test. > > Funny thing jumped out at me here... I was taught about oop in terms of > > message passing: there is no conceptual difference between passing a > > message and a 'remote object invocation'. > > Yeah. Indeed, I don't need the remote object part - I have the data > model well under control. I just need to pass events. [yes, of course, a > Remote Entity model DOES do what I need - just seems overly complicated > is all] I guess that comes from whether you consider your app a collection of objects interacting, or a collection of data you are manipulating :), From rom an OOP point of view (and java is reputed to be an OOP language) - serialisation to data and back again is a /lot/ harder than message passing. > Given the relatively small size of the groups involved here, polling > doesn't create a resource constraint issue, but it is inelegant at best, > and certainly doesn't scale. > > No, the only real trouble that I can see is that in the wider public > network context, the firewall problem gets in the way - clients can > connect outbound to some server on the net, but (especially in an HTTP > paradigm) the other direction doesn't fly. (oh, sure you can pass > messages in response to a poll, but you can't initiate). I don't think I > want to write something that is constrained to the immediate LAN only. So there are three typical models to tunnel through a firewall without needing the admin to cooperate: 1) udp dual-connect: both ends connect at the same time, and many firewalls will let traffic flow happily. More cautious networks though will not allow random udp protocol through at all: 2) outbound connections: the secured server connects out to the roaming client (use a mobile phone or some such to setup the details) and then its bidirectional over the tcp link. more cautious networks won't allow random tcp ports either: so connect to port 443, and support http proxies. 3) plug a modem in. Rob -- GPG key available at: <http://www.robertcollins.net/keys.txt>.
signature.asc
Description: This is a digitally signed message part
-- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
