From david at mantara.com Tue Jan 2 20:47:51 2007 From: david at mantara.com (David Arnold) Date: Tue Jan 2 20:48:16 2007 Subject: [elvin-discuss] Re: Elvin spec In-Reply-To: References: <20816.1166735296@d.0x1.org> <283BBE0E-1115-4F58-B889-01BAAEA13762@mantara.com> Message-ID: On 28/12/2006, at 2:50 PM, Matthew Phillips wrote: > On 28/12/2006, at 9:28 AM, David Arnold wrote: >> On 22/12/2006, at 10:48 AM, Ian Lister wrote: >> >> ok, so: any objections to the option named >> >> TCP.Send-Immediately >> >> being set true to mean that Nagle's algorithm should be disabled >> for a connection (overriding the default which SHOULD be false)? > > Fine by me. ok. i'll update and push another draft of the spec. > Are there any other planned changes to the spec? i *think* (bear with me, i'm at the beach, and recall is not at its best :-) that the major remaining issue is tidying up the error codes. there's a few non-standard numbers, etc, that have crept into Mantara's elvind, and i'd like to make sure the spec covers the errors in use, and that they've got sane numbers. > Actually, now I think about it, one minor thing that I would like > to add is a "not implemented" NACK code for use by implementations > that do a subset of the spec. Or perhaps a way to indicate that via > connection options, similar to "Supported-Key-Schemes". e.g. > "Supported-Protocol-Subsets: A, B". yeah. i'd like to do both, actually. most important is the NACK code, i think. there's not much alternative for a client library than passing back a NOT_SUPPORTED to the application, but given it's allowable to have routers without quench, etc, it's gotta be reported somehow. of course, it'd also be good to have this advertised in the ConnRply options so the client's options callback can reject the connection. as it happens, this ties in nicely with some work we did in 4.4 to deal with authorisation: it's possible to disallow clients access to subscription or quench (or notification). that ended up being advertised using named options. i'm not sure whether to try to push those options back in the 4.0 protocol spec, or not. it's tempting though ... ? we still have to add the extra packet from the 4.1 protocol, and then the authentication support from 4.4 ... i'd prefer to put that into subsequent spec versions (and get 4.0 finished), but i guess we should consider what you'd like to do with Avis, Matt? d From matt at mattp.name Tue Jan 2 21:35:23 2007 From: matt at mattp.name (Matthew Phillips) Date: Tue Jan 2 21:35:39 2007 Subject: [elvin-discuss] Re: Elvin spec In-Reply-To: References: <20816.1166735296@d.0x1.org> <283BBE0E-1115-4F58-B889-01BAAEA13762@mantara.com> Message-ID: <9532F174-9126-45D7-9E42-60B46938E43D@mattp.name> On 03/01/2007, at 1:17 PM, David Arnold wrote: > On 28/12/2006, at 2:50 PM, Matthew Phillips wrote: >> On 28/12/2006, at 9:28 AM, David Arnold wrote: >> Actually, now I think about it, one minor thing that I would like >> to add is a "not implemented" NACK code for use by implementations >> that do a subset of the spec. Or perhaps a way to indicate that >> via connection options, similar to "Supported-Key-Schemes". e.g. >> "Supported-Protocol-Subsets: A, B". > > yeah. i'd like to do both, actually. > > most important is the NACK code, i think. there's not much > alternative for a client library than passing back a NOT_SUPPORTED > to the application, but given it's allowable to have routers > without quench, etc, it's gotta be reported somehow. Yep. I've made up an error code for now that je4 seems to handle OK, which at least allows Sticker's setup wizard to work (it uses quench to guess what presence groups are active). But that this works is obviously more by luck than by design. And I don't know how the other client libraries will deal with it either... > of course, it'd also be good to have this advertised in the > ConnRply options so the client's options callback can reject the > connection. You mean the client would request certain capabilities in the connection options and the router would ACK/NACK them? Or just that the server sends to client what it can do same as "Supported-Key- Schemes"? > as it happens, this ties in nicely with some work we did in 4.4 to > deal with authorisation: it's possible to disallow clients access > to subscription or quench (or notification). that ended up being > advertised using named options. > > i'm not sure whether to try to push those options back in the 4.0 > protocol spec, or not. it's tempting though ... ? > > we still have to add the extra packet from the 4.1 protocol, and > then the authentication support from 4.4 ... i'd prefer to put that > into subsequent spec versions (and get 4.0 finished), but i guess > we should consider what you'd like to do with Avis, Matt? Since Avis 1.0 will do the A & B subsets, the only remaining basic requirement for getting to release stage now is to just have a sensible way to advertise that, and be able to bounce C-level stuff appropriately. So, if it's possible to back-port to 4.0 an extendable subset of whatever will be in 4.4 for indicating what capabilities a client can exercise with the router, that would seem like a sensible approach. Then the development path would be for subsequent Avis releases to track spec updates. Enjoy the beach! Matt. From ilister at mantara.com Thu Jan 4 23:54:34 2007 From: ilister at mantara.com (Ian Lister) Date: Thu Jan 4 23:54:48 2007 Subject: [elvin-discuss] Re: Elvin spec In-Reply-To: References: <20816.1166735296@d.0x1.org> <283BBE0E-1115-4F58-B889-01BAAEA13762@mantara.com> Message-ID: On Wed, 3 Jan 2007, David Arnold wrote: > i *think* (bear with me, i'm at the beach, and recall is not at its best :-) > that the major remaining issue is tidying up the error codes. there's a few > non-standard numbers, etc, that have crept into Mantara's elvind, and i'd > like to make sure the spec covers the errors in use, and that they've got > sane numbers. Good. >> Actually, now I think about it, one minor thing that I would like to add is >> a "not implemented" NACK code for use by implementations that do a subset >> of the spec. Or perhaps a way to indicate that via connection options, >> similar to "Supported-Key-Schemes". e.g. "Supported-Protocol-Subsets: A, >> B". > > yeah. i'd like to do both, actually. FWIW I dislike the "Protocol-Subset: A" business. I'd much rather something more like what we do for authorisation in 4.4 e.g. "Supports-Subscription: 1" (or just "Can-Subscribe: 1") or whatever. > most important is the NACK code, i think. there's not much alternative for a > client library than passing back a NOT_SUPPORTED to the application, but > given it's allowable to have routers without quench, etc, it's gotta be > reported somehow. NO_ROUTER_SUPPORT, of course. If you got a NOT_SUPPORTED (implying the lack of support is local) you'd just give up and go home, but with NO_ROUTER_SUPPORT it's worth continuing to try other routers. > of course, it'd also be good to have this advertised in the ConnRply options > so the client's options callback can reject the connection. And in real service discovery too: ERDP (if we continue to develop it), a standard DNS TXT format (for DNS-SD), and whatever else. > as it happens, this ties in nicely with some work we did in 4.4 to deal with > authorisation: it's possible to disallow clients access to subscription or > quench (or notification). that ended up being advertised using named > options. > > i'm not sure whether to try to push those options back in the 4.0 protocol > spec, or not. it's tempting though ... ? Resist! :-) They're an extra feature that's only just now being deployed and can be added to the spec later without breakage. (Although if there's some incompatibility potentially caused by adding it later we should change the 4.0 draft spec to remove that and allow us to add the feature to the spec later without incompatibility, of course) > we still have to add the extra packet from the 4.1 protocol, and then the > authentication support from 4.4 ... i'd prefer to put that into subsequent > spec versions (and get 4.0 finished), Good plan :-) > but i guess we should consider what > you'd like to do with Avis, Matt? Ship it! Oh, sorry... :-) Cheers, Ian From matt at mattp.name Fri Jan 5 02:16:39 2007 From: matt at mattp.name (Matthew Phillips) Date: Fri Jan 5 02:16:57 2007 Subject: [elvin-discuss] Re: Elvin spec In-Reply-To: References: <20816.1166735296@d.0x1.org> <283BBE0E-1115-4F58-B889-01BAAEA13762@mantara.com> Message-ID: <32685095-C46F-4544-8C28-0BF5C03B34F2@mattp.name> On 05/01/2007, at 4:24 PM, Ian Lister wrote: > On Wed, 3 Jan 2007, David Arnold wrote: >>> Actually, now I think about it, one minor thing that I would like >>> to add is a "not implemented" NACK code for use by >>> implementations that do a subset of the spec. Or perhaps a way to >>> indicate that via connection options, similar to "Supported-Key- >>> Schemes". e.g. "Supported-Protocol-Subsets: A, B". >> >> yeah. i'd like to do both, actually. > > FWIW I dislike the "Protocol-Subset: A" business. I'd much rather > something more like what we do for authorisation in 4.4 e.g. > "Supports-Subscription: 1" (or just "Can-Subscribe: 1") or whatever. Alright, but for neatness sake it might be nice to use a prefix for capability fields, e.g. "Capability.Subscribe", "Capability.Quench", etc. Doesn't fit with how it's done in Supported-Key-Schemes, but... >> most important is the NACK code, i think. there's not much >> alternative for a client library than passing back a NOT_SUPPORTED >> to the application, but given it's allowable to have routers >> without quench, etc, it's gotta be reported somehow. > > NO_ROUTER_SUPPORT, of course. If you got a NOT_SUPPORTED (implying > the lack of support is local) you'd just give up and go home, but > with NO_ROUTER_SUPPORT it's worth continuing to try other routers. Not sure what the difference is? Either a request is recognised but not supported or it's a protocol violation surely? >> of course, it'd also be good to have this advertised in the >> ConnRply options so the client's options callback can reject the >> connection. > > And in real service discovery too: ERDP (if we continue to develop > it), a standard DNS TXT format (for DNS-SD), and whatever else. Hmm, I have no idea what any of that means :) But it's an opportunity to point out that I'm thinking that advertising the router using mDNS (Bonjour) might be a useful thing to do. Any opinions? >> as it happens, this ties in nicely with some work we did in 4.4 to >> deal with authorisation: it's possible to disallow clients access >> to subscription or quench (or notification). that ended up being >> advertised using named options. >> >> i'm not sure whether to try to push those options back in the 4.0 >> protocol spec, or not. it's tempting though ... ? > > Resist! :-) > > They're an extra feature that's only just now being deployed and > can be added to the spec later without breakage. > > (Although if there's some incompatibility potentially caused by > adding it later we should change the 4.0 draft spec to remove that > and allow us to add the feature to the spec later without > incompatibility, of course) Yes, I think that was also the gist of my response too. >> but i guess we should consider what you'd like to do with Avis, Matt? > > Ship it! > > Oh, sorry... :-) Would love to ;) And in fact I think it's very close. Just need to clear up this issue and get in a little more field-testing with the deployment packages and then I'll qualify for my Ship It! award. Matt. From ilister at mantara.com Mon Jan 8 00:01:23 2007 From: ilister at mantara.com (Ian Lister) Date: Mon Jan 8 00:01:55 2007 Subject: [elvin-discuss] Re: Elvin spec In-Reply-To: <32685095-C46F-4544-8C28-0BF5C03B34F2@mattp.name> References: <20816.1166735296@d.0x1.org> <283BBE0E-1115-4F58-B889-01BAAEA13762@mantara.com> <32685095-C46F-4544-8C28-0BF5C03B34F2@mattp.name> Message-ID: <20070105183046.X1229@trappist.lister.id.au> On Fri, 5 Jan 2007, Matthew Phillips wrote: > On 05/01/2007, at 4:24 PM, Ian Lister wrote: >> On Wed, 3 Jan 2007, David Arnold wrote: >>> most important is the NACK code, i think. there's not much alternative >>> for a client library than passing back a NOT_SUPPORTED to the application, >>> but given it's allowable to have routers without quench, etc, it's gotta >>> be reported somehow. >> >> NO_ROUTER_SUPPORT, of course. If you got a NOT_SUPPORTED (implying the lack >> of support is local) you'd just give up and go home, but with >> NO_ROUTER_SUPPORT it's worth continuing to try other routers. > > Not sure what the difference is? Either a request is recognised but not > supported or it's a protocol violation surely? If the lack of support is local (e.g. your client library implementation doesn't support quench) there's no request at all. >>> of course, it'd also be good to have this advertised in the ConnRply >>> options so the client's options callback can reject the connection. >> >> And in real service discovery too: ERDP (if we continue to develop it), a >> standard DNS TXT format (for DNS-SD), and whatever else. > > Hmm, I have no idea what any of that means :) But it's an opportunity to > point out that I'm thinking that advertising the router using mDNS (Bonjour) > might be a useful thing to do. Any opinions? Yes, Bonjour consists of IPv4LL (addressing), mDNS (naming) and DNS-SD (discovery). ERDP is the existing Elvin Router Discovery Protocol. Cheers, Ian From david at mantara.com Mon Jan 8 06:51:11 2007 From: david at mantara.com (David Arnold) Date: Mon Jan 8 06:51:19 2007 Subject: [elvin-discuss] Re: Elvin spec In-Reply-To: Your message of "Wed, 03 Jan 2007 14:05:23 +1030." <9532F174-9126-45D7-9E42-60B46938E43D@mattp.name> Message-ID: <18703.1168260671@d.0x1.org> -->"Matt" == Matthew Phillips writes: >> most important is the NACK code, i think. there's not much >> alternative for a client library than passing back a NOT_SUPPORTED >> to the application, but given it's allowable to have routers >> without quench, etc, it's gotta be reported somehow. Matt> Yep. I've made up an error code for now that je4 seems to handle Matt> OK, which at least allows Sticker's setup wizard to work (it Matt> uses quench to guess what presence groups are active). But that Matt> this works is obviously more by luck than by design. And I don't Matt> know how the other client libraries will deal with it either... what code did you use, out of interest? >> of course, it'd also be good to have this advertised in the >> ConnRply options so the client's options callback can reject the >> connection. Matt> You mean the client would request certain capabilities in the Matt> connection options and the router would ACK/NACK them? Or just Matt> that the server sends to client what it can do same as Matt> "Supported-Key- Schemes"? effectively the latter. Matt> Since Avis 1.0 will do the A & B subsets, the only remaining Matt> basic requirement for getting to release stage now is to just Matt> have a sensible way to advertise that, and be able to bounce Matt> C-level stuff appropriately. i think we can actually get away with returning a Nack only. no existing client library (with the possible exception of libelvin 4.4.x) would understand that advertisement of the feature set anyway ... JE4 and PE4 handle unknown error codes nicely. libelvin has been less nice in the past; i'm not sure exactly what it's doing now. Matt> Enjoy the beach! thanks, i did :-) d From matt at mattp.name Wed Jan 10 16:06:39 2007 From: matt at mattp.name (Matthew Phillips) Date: Wed Jan 10 16:07:30 2007 Subject: [elvin-discuss] Re: Elvin spec In-Reply-To: <20070105183046.X1229@trappist.lister.id.au> References: <20816.1166735296@d.0x1.org> <283BBE0E-1115-4F58-B889-01BAAEA13762@mantara.com> <32685095-C46F-4544-8C28-0BF5C03B34F2@mattp.name> <20070105183046.X1229@trappist.lister.id.au> Message-ID: On 08/01/2007, at 4:31 PM, Ian Lister wrote: > On Fri, 5 Jan 2007, Matthew Phillips wrote: >> On 05/01/2007, at 4:24 PM, Ian Lister wrote: >>> On Wed, 3 Jan 2007, David Arnold wrote: >>>> most important is the NACK code, i think. there's not much >>>> alternative for a client library than passing back a >>>> NOT_SUPPORTED to the application, but given it's allowable to >>>> have routers without quench, etc, it's gotta be reported somehow. >>> NO_ROUTER_SUPPORT, of course. If you got a NOT_SUPPORTED >>> (implying the lack of support is local) you'd just give up and go >>> home, but with NO_ROUTER_SUPPORT it's worth continuing to try >>> other routers. >> >> Not sure what the difference is? Either a request is recognised >> but not supported or it's a protocol violation surely? > > If the lack of support is local (e.g. your client library > implementation doesn't support quench) there's no request at all. OK. But I would have thought the client library would have better ways of reporting (fixed) lack of support for a feature. >>>> of course, it'd also be good to have this advertised in the >>>> ConnRply options so the client's options callback can reject the >>>> connection. >>> And in real service discovery too: ERDP (if we continue to >>> develop it), a standard DNS TXT format (for DNS-SD), and whatever >>> else. >> >> Hmm, I have no idea what any of that means :) But it's an >> opportunity to point out that I'm thinking that advertising the >> router using mDNS (Bonjour) might be a useful thing to do. Any >> opinions? > > Yes, Bonjour consists of IPv4LL (addressing), mDNS (naming) and DNS- > SD (discovery). ERDP is the existing Elvin Router Discovery Protocol. Sounds like what I want then ;) Is ERDP something that should/would be opened up? Matt. From matt at mattp.name Wed Jan 10 16:14:29 2007 From: matt at mattp.name (Matthew Phillips) Date: Wed Jan 10 16:15:22 2007 Subject: [elvin-discuss] Re: Elvin spec In-Reply-To: <18703.1168260671@d.0x1.org> References: <18703.1168260671@d.0x1.org> Message-ID: <0E3E4728-38BB-4F09-B2F8-9104972A6565@mattp.name> On 08/01/2007, at 11:21 PM, David Arnold wrote: > -->"Matt" == Matthew Phillips writes: > >>> most important is the NACK code, i think. there's not much >>> alternative for a client library than passing back a NOT_SUPPORTED >>> to the application, but given it's allowable to have routers >>> without quench, etc, it's gotta be reported somehow. > > Matt> Yep. I've made up an error code for now that je4 seems to > handle > Matt> OK, which at least allows Sticker's setup wizard to work (it > Matt> uses quench to guess what presence groups are active). But > that > Matt> this works is obviously more by luck than by design. And I > don't > Matt> know how the other client libraries will deal with it > either... > > what code did you use, out of interest? Top of the quench error range: 2299. Makes sure it looks bogus but still handled semi-intelligently by clients (je4 reports unknown error but seems to get the idea that it's not on the client side). > Matt> Since Avis 1.0 will do the A & B subsets, the only remaining > Matt> basic requirement for getting to release stage now is to just > Matt> have a sensible way to advertise that, and be able to bounce > Matt> C-level stuff appropriately. > > i think we can actually get away with returning a Nack only. > > no existing client library (with the possible exception of libelvin > 4.4.x) would understand that advertisement of the feature set > anyway ... OK. The (non-existent) Avis Java client library won't have quench either in the first release, so I guess knowing whether the router supports it is interesting but academic. So, if we can get a NOT_IMPL error code spec'd, that's all I need. Matt. From ilister at mantara.com Wed Jan 10 17:20:30 2007 From: ilister at mantara.com (Ian Lister) Date: Wed Jan 10 17:20:52 2007 Subject: [elvin-discuss] Re: Elvin spec In-Reply-To: References: <20816.1166735296@d.0x1.org> <283BBE0E-1115-4F58-B889-01BAAEA13762@mantara.com> <32685095-C46F-4544-8C28-0BF5C03B34F2@mattp.name> <20070105183046.X1229@trappist.lister.id.au> Message-ID: On Thu, 11 Jan 2007, Matthew Phillips wrote: > On 08/01/2007, at 4:31 PM, Ian Lister wrote: >> If the lack of support is local (e.g. your client library implementation >> doesn't support quench) there's no request at all. > > OK. But I would have thought the client library would have better ways of > reporting (fixed) lack of support for a feature. Reporting an error when you try to use unsupported API seems to be a sensible way to do it. There's a defined error code for this, which is NOT_SUPPORTED. There's also a defined error code for the case where the router you are connected to doesn't support something you're trying to do, which is NO_ROUTER_SUPPORT. >> Yes, Bonjour consists of IPv4LL (addressing), mDNS (naming) and DNS-SD >> (discovery). ERDP is the existing Elvin Router Discovery Protocol. > > Sounds like what I want then ;) Is ERDP something that should/would be opened > up? It is. It's listed at but the link is broken. I'll see what we can do about that. Cheers, Ian From david at mantara.com Wed Jan 10 17:23:26 2007 From: david at mantara.com (David Arnold) Date: Wed Jan 10 17:23:32 2007 Subject: [elvin-discuss] Re: Elvin spec In-Reply-To: Your message of "Thu, 11 Jan 2007 09:20:30 +1000." Message-ID: <5715.1168471406@d.0x1.org> -->"Ian" == Ian Lister writes: Ian> Reporting an error when you try to use unsupported API seems to Ian> be a sensible way to do it. There's a defined error code for Ian> this, which is NOT_SUPPORTED. Ian> There's also a defined error code for the case where the router Ian> you are connected to doesn't support something you're trying to Ian> do, which is NO_ROUTER_SUPPORT. neither of those error codes are _protocol_ errors. they're Mantara-specific libelvin error codes. d From ilister at mantara.com Wed Jan 10 17:29:18 2007 From: ilister at mantara.com (Ian Lister) Date: Wed Jan 10 17:29:37 2007 Subject: [elvin-discuss] Re: Elvin spec In-Reply-To: <5715.1168471406@d.0x1.org> References: <5715.1168471406@d.0x1.org> Message-ID: On Thu, 11 Jan 2007, David Arnold wrote: [Re: NOT_SUPPORTED and NO_ROUTER_SUPPORT] > neither of those error codes are _protocol_ errors. they're > Mantara-specific libelvin error codes. Right, because this is in reply to: On Wed, 3 Jan 2007, David Arnold wrote: > most important is the NACK code, i think. there's not much > alternative for a client library than passing back a NOT_SUPPORTED to > the application, but given it's allowable to have routers without > quench, etc, it's gotta be reported somehow. What the client library passes back to the application is the API, not the protocol, and NOT_SUPPORTED is a Mantara libelvin error code. Ian From davida at pobox.com Wed Jan 10 17:54:30 2007 From: davida at pobox.com (David Arnold) Date: Wed Jan 10 17:54:46 2007 Subject: [elvin-discuss] Re: Elvin spec In-Reply-To: Your message of "Thu, 11 Jan 2007 08:36:39 +1030." Message-ID: <5992.1168473270@d.0x1.org> -->"Matt" == Matthew Phillips writes: Matt> On 08/01/2007, at 4:31 PM, Ian Lister wrote: >> On Fri, 5 Jan 2007, Matthew Phillips wrote: >>> On 05/01/2007, at 4:24 PM, Ian Lister wrote: >>>> On Wed, 3 Jan 2007, David Arnold wrote: >>>>> most important is the NACK code, i think. there's not much >>>>> alternative for a client library than passing back a >>>>> NOT_SUPPORTED to the application, but given it's allowable to >>>>> have routers without quench, etc, it's gotta be reported >>>>> somehow. >>>> NO_ROUTER_SUPPORT, of course. If you got a NOT_SUPPORTED >>>> (implying the lack of support is local) you'd just give up and go >>>> home, but with NO_ROUTER_SUPPORT it's worth continuing to try >>>> other routers. >>> Not sure what the difference is? Either a request is recognised >>> but not supported or it's a protocol violation surely? >> If the lack of support is local (e.g. your client library >> implementation doesn't support quench) there's no request at all. Matt> OK. But I would have thought the client library would have Matt> better ways of reporting (fixed) lack of support for a feature. some client libraries (ie. Mantara's libelvin) distinguish between things not supported by the client library (elvin_error_t code NOT_SUPPORTED) and things not supported by the currently connected router (NO_ROUTER_SUPPORT). since in the latter case you can connect to a different router to try to get the functionality, it's a distinction that can be valuable. >> Yes, Bonjour consists of IPv4LL (addressing), mDNS (naming) and >> DNS- SD (discovery). ERDP is the existing Elvin Router Discovery >> Protocol. Matt> Sounds like what I want then ;) Is ERDP something that Matt> should/would be opened up? what would you like first: discovery or federation? (just so i know where to focus my copious spare time :-) d From davida at pobox.com Wed Jan 10 18:10:36 2007 From: davida at pobox.com (David Arnold) Date: Wed Jan 10 18:10:45 2007 Subject: [elvin-discuss] Re: Elvin spec In-Reply-To: Your message of "Thu, 11 Jan 2007 08:44:29 +1030." <0E3E4728-38BB-4F09-B2F8-9104972A6565@mattp.name> Message-ID: <6073.1168474236@d.0x1.org> -->"Matt" == Matthew Phillips writes: Matt> Yep. I've made up an error code for now that je4 seems to handle Matt> OK, which at least allows Sticker's setup wizard to work (it Matt> uses quench to guess what presence groups are active). But that Matt> this works is obviously more by luck than by design. And I don't Matt> know how the other client libraries will deal with it either... >> what code did you use, out of interest? Matt> Top of the quench error range: 2299. Makes sure it looks bogus Matt> but still handled semi-intelligently by clients (je4 reports Matt> unknown error but seems to get the idea that it's not on the Matt> client side). see je4/src/org/elvin/je4/ConnectionRequests.java, handleNack() for the code which handles errors. i'd prefer to see it in the general request errors area, since it could reasonably be returned by a router that doesn't support subscription, or QoS modification, or other things in future too. i think 2007 is the next free error code, so i'm proposing we use that. >> no existing client library (with the possible exception of libelvin >> 4.4.x) would understand that advertisement of the feature set >> anyway ... Matt> OK. The (non-existent) Avis Java client library won't have Matt> quench either in the first release, so I guess knowing whether Matt> the router supports it is interesting but academic. Matt> So, if we can get a NOT_IMPL error code spec'd, that's all I Matt> need. anyone about to using 2007 for this purpose? d From davida at pobox.com Wed Jan 10 22:09:12 2007 From: davida at pobox.com (David Arnold) Date: Wed Jan 10 22:09:27 2007 Subject: [elvin-discuss] Re: Elvin spec In-Reply-To: Your message of "Thu, 11 Jan 2007 09:29:18 +1000." Message-ID: <8162.1168488552@d.0x1.org> -->"Ian" == Ian Lister writes: >> neither of those error codes are _protocol_ errors. they're >> Mantara-specific libelvin error codes. Ian> Right, because this is in reply to: Ian> On Wed, 3 Jan 2007, David Arnold wrote: >> most important is the NACK code, i think. there's not much >> alternative for a client library than passing back a NOT_SUPPORTED >> to the application, but given it's allowable to have routers >> without quench, etc, it's gotta be reported somehow. Ian> What the client library passes back to the application is the Ian> API, not the protocol, and NOT_SUPPORTED is a Mantara libelvin Ian> error code. ok. what is required, i think, is a way for the router to inform the client library that a requested feature is not supported. i'm proposing that we use Nack error code 2007 for this. whether a client library enables an application to distinguish between NOT_SUPPORTED and NO_ROUTER_SUPPORT, and how it choses to report those conditions, is beyond the scope of the protocol spec, imo. d From ilister at mantara.com Wed Jan 10 22:22:52 2007 From: ilister at mantara.com (Ian Lister) Date: Wed Jan 10 22:23:14 2007 Subject: [elvin-discuss] Re: Elvin spec In-Reply-To: <8162.1168488552@d.0x1.org> References: <8162.1168488552@d.0x1.org> Message-ID: On Thu, 11 Jan 2007, David Arnold wrote: > what is required, i think, is a way for the router to inform the client > library that a requested feature is not supported. i'm proposing that > we use Nack error code 2007 for this. Sure. No problem with that. For recognised but unsupported features requested in the ConnRqst, the router would still send a ConnRply though, right? > whether a client library enables an application to distinguish between > NOT_SUPPORTED and NO_ROUTER_SUPPORT, and how it choses to report those > conditions, is beyond the scope of the protocol spec, imo. Absolutely. As you mentioned, the client library doesn't have much choice (or the choice is fairly obvious). I was just pointing out that the suggested NOT_SUPPORTED (a libelvin API error code) is not what that implementation would (or should) report to the application. Ian From david at mantara.com Wed Jan 10 23:32:30 2007 From: david at mantara.com (David Arnold) Date: Wed Jan 10 23:32:37 2007 Subject: [elvin-discuss] Re: Elvin spec In-Reply-To: Your message of "Thu, 11 Jan 2007 14:22:52 +1000." Message-ID: <8758.1168493550@d.0x1.org> -->"Ian" == Ian Lister writes: Ian> On Thu, 11 Jan 2007, David Arnold wrote: >> what is required, i think, is a way for the router to inform the >> client library that a requested feature is not supported. i'm >> proposing that we use Nack error code 2007 for this. Ian> Sure. No problem with that. Ok, good. I'll try to push an -05 spec draft today with both that and the TCP.Send-Immediately option included. Ian> For recognised but unsupported features requested in the Ian> ConnRqst, the router would still send a ConnRply though, right? yeah. protocol v4.0 clients don't have a way to request features in the ConnRqst, so this spec will say nothing about that. once the Mantara-4.4.x functionality is specified, i think the notify/subscribe/quench request option processing would be work the same as it does for auth (ie. what the router is prepared to give you is sent in the ConnRply). d From davida at pobox.com Thu Jan 11 01:29:59 2007 From: davida at pobox.com (David Arnold) Date: Thu Jan 11 01:38:12 2007 Subject: [elvin-discuss] Elvin Client Protocol 4.0 draft 5 Message-ID: <9511.1168500599@d.0x1.org> this afternoon i published the latest revision of the client protocol specification http://www.elvin.org/specs/draft-elvin-client-40-05.txt of particular note, the changes include - added the TCP.Send-Immediately connection option - added the NOT_IMPL Nack error code - changed the names of all standard connection options other changes from -04 are - revised the overview text, reverting to use "notification" to describe the delivered messages and expanding the discussion of notification, subscription and quenching, hopefully making it clearer for neophytes - corrected various errors in the protocol overview diagrams - clarified and corrected the description of the subscription language, especially the format of literal values - corrected references to the "sizeof" function to be "size" (thanks Matt) - clarified and corrected the description of several subscription language functions - corrected Unicode references to use U+XXXX syntax, not \uXXXX - added a discussion of connection/QoS option names, negotiation process and individual option semantics - noted the connection option names used by Mantara's router and suggested compatibility work-arounds be implemented - various formatting fixes many of these changes stem from Matt's work on Avis, and give me some hope that we're close to having a useful specification. my plan is to work on removing the remaining known issues (most highlighted with FIXME) in the text, and then call for a final pre-publication review. thanks, d From matt at mattp.name Fri Jan 12 19:31:12 2007 From: matt at mattp.name (Matthew Phillips) Date: Fri Jan 12 19:32:24 2007 Subject: [elvin-discuss] Re: Elvin spec In-Reply-To: <5992.1168473270@d.0x1.org> References: <5992.1168473270@d.0x1.org> Message-ID: On 11/01/2007, at 10:24 AM, David Arnold wrote: > -->"Matt" == Matthew Phillips writes: > > Matt> Sounds like what I want then ;) Is ERDP something that > Matt> should/would be opened up? > > what would you like first: discovery or federation? Since we can muddle on with the ewafd approach in the short term, I'd pick discovery I guess. > (just so i know where to focus my copious spare time :-) Well, certainly don't waste any more of it at the beach ... we're waiting with bated breath for exciting new specs here ;) Matt. From davida at pobox.com Mon Jan 15 05:37:41 2007 From: davida at pobox.com (David Arnold) Date: Mon Jan 15 05:37:51 2007 Subject: [elvin-discuss] Elvin Client Protocol 4.0 draft 5 In-Reply-To: Your message of "Mon, 15 Jan 2007 20:13:29 +1030." Message-ID: <640.1168861061@d.0x1.org> -->"Matt" == Matthew Phillips writes: Matt> On 11/01/2007, at 5:59 PM, David Arnold wrote: >> - added a discussion of connection/QoS option names, negotiation >> process and individual option semantics Matt> Is a description of the QOS packets still on the cards? oh, yeah, i suppose i should ... :-) Matt> Do any client libs except the C one support it? i don't think any of the current client libraries implement it, actually. Matt> I've updated Avis to match the new spec. So I think all that's Matt> needed now are a few configuration file additions and other Matt> minor cleanups and I can slap a 1.0 beta sticker on it. yay! Matt> I was also hoping for some feedback from the people that have Matt> apparently downloaded Avis 130 times, but been very quiet so Matt> far. The lack of comment is either a very good or very bad sign Matt> ;) if my experience with elvind at DSTC is an indicator, silence means either that they installed it but couldn't figure out how to change the UI theme before getting distracted, or it works fine :-) d From scramjet at internode.on.net Mon Jan 15 03:43:29 2007 From: scramjet at internode.on.net (Matthew Phillips) Date: Mon Jan 15 14:22:26 2007 Subject: [elvin-discuss] Elvin Client Protocol 4.0 draft 5 In-Reply-To: <9511.1168500599@d.0x1.org> References: <9511.1168500599@d.0x1.org> Message-ID: On 11/01/2007, at 5:59 PM, David Arnold wrote: > - added a discussion of connection/QoS option names, negotiation > process > and individual option semantics Is a description of the QOS packets still on the cards? Do any client libs except the C one support it? I've updated Avis to match the new spec. So I think all that's needed now are a few configuration file additions and other minor cleanups and I can slap a 1.0 beta sticker on it. I was also hoping for some feedback from the people that have apparently downloaded Avis 130 times, but been very quiet so far. The lack of comment is either a very good or very bad sign ;) Matt. From davida at pobox.com Mon Jan 15 22:07:09 2007 From: davida at pobox.com (David Arnold) Date: Mon Jan 15 22:07:25 2007 Subject: [elvin-discuss] Elvin Router Discovery Protocol draft-00 Message-ID: <487.1168920429@d.0x1.org> i've published a first draft of the Elvin Router Discovery Protocol (ERDP) specification today. it's available at http://www.elvin.org/specs/draft-elvin-router-discovery-00.txt corrections, questions, etc, welcome, d From matt at mattp.name Sun Jan 21 22:21:08 2007 From: matt at mattp.name (Matthew Phillips) Date: Sun Jan 21 22:21:16 2007 Subject: [elvin-discuss] Elvin URI spec questions Message-ID: <873ABAB8-4E17-4377-A40B-EA1453D4C1A8@mattp.name> Hi all, just writing a parser for Elvin URI's and noticed what seems like an inconsistency in the protocol spec. The default protocol stack defined in 5.1.2 is: tcp,none,xdr while the "secure" stack is: ssl,none,xdr I'm assuming, if the (transport,security,marshalling) ordering matters, that this should be "tcp,ssl,xdr"? The spec doesn't actually nail down the (transport,security,marshalling) structure, so I'm just guessing, but this seems to be what all the client accept. Matt. From davida at pobox.com Wed Feb 21 03:04:18 2007 From: davida at pobox.com (David Arnold) Date: Wed Feb 21 03:04:30 2007 Subject: [elvin-discuss] Elvin URI spec questions In-Reply-To: Your message of "Mon, 22 Jan 2007 14:51:08 +1030." <873ABAB8-4E17-4377-A40B-EA1453D4C1A8@mattp.name> Message-ID: <29038.1172048658@d.0x1.org> -->"Matt" == Matthew Phillips writes: hi Matt, sorry about the delay in responding ... :-( Matt> just writing a parser for Elvin URI's and noticed what Matt> seems like an inconsistency in the protocol spec. The default Matt> protocol stack defined in 5.1.2 is: Matt> tcp,none,xdr Matt> while the "secure" stack is: Matt> ssl,none,xdr Matt> I'm assuming, if the (transport,security,marshalling) ordering Matt> matters, that this should be "tcp,ssl,xdr"? you've just stumbled over the first of several problems with the Elvin URL scheme as it is implemented today. it's reasonable to implement SSL as a transparent encryption layer over any underlying transport. but ... in Mantara's implementation, the 'ssl' protocol is a transport that uses SSL over TCP. there are no existing security modules. Matt> The spec doesn't actually nail down the Matt> (transport,security,marshalling) structure, so I'm just Matt> guessing, but this seems to be what all the client accept. going forward, we tend to talk about the n-layer stack. there are several types of modules: - one that takes a packet structure/object, and converts it to an array of bytes and vice versa. this is what the current Mantara 'xdr' and 'xml' modules do, and could reasonably be called 'marshalling'. - one that takes an array of bytes and gives an array of bytes. for instance, doing encryption or compression. - one that writes and reads arrays of bytes to and from the network. this is what the current 'tcp', 'udp', 'ssl', and 'unix' modules do, and we've always called 'transport'. - a final possiblity is a module that takes a packet structure/object, modifies it, and passes it on. i haven't yet come up with a good reason for doing this in the protocol stack, but it might be reasonable for something? a protocol *stack* must put and get packet structure/objects onto the network. this could require a single combined module, or a stack like /tcp,aes,gzip,xdr/ (for instance). what's missing at elvin.org is the spec for what each of the module names means. eg. if a URL includes 'tcp', what exactly should be done to interpret that data? there's skeletons in CVS, but no useful content. the URL spec should support stacks of 1..N of these modules, so long as the interfaces between them match up. it'd be totally reasonable to define an 'ssl2' or 'ssl-enc' or something which means SSL over any underlying transport, but until now, it hasn't been a priority. hope this helps ... d From matt at mattp.name Fri Feb 23 20:59:50 2007 From: matt at mattp.name (Matthew Phillips) Date: Fri Feb 23 21:04:00 2007 Subject: [elvin-discuss] Elvin URI spec questions In-Reply-To: <29038.1172048658@d.0x1.org> References: <29038.1172048658@d.0x1.org> Message-ID: On 21/02/2007, at 7:34 PM, David Arnold wrote: > -->"Matt" == Matthew Phillips writes: > > hi Matt, > > sorry about the delay in responding ... :-( No worries, I gather you've been pretty busy and/or not in the country ;) > you've just stumbled over the first of several problems with the Elvin > URL scheme as it is implemented today. > > it's reasonable to implement SSL as a transparent encryption layer > over > any underlying transport. but ... in Mantara's implementation, the > 'ssl' protocol is a transport that uses SSL over TCP. Ah, it becomes clear. > there are no existing security modules. > Matt> The spec doesn't actually nail down the > Matt> (transport,security,marshalling) structure, so I'm just > Matt> guessing, but this seems to be what all the client accept. > > going forward, we tend to talk about the n-layer stack. > the URL spec should support stacks of 1..N of these modules, so > long as > the interfaces between them match up. > > it'd be totally reasonable to define an 'ssl2' or 'ssl-enc' or > something > which means SSL over any underlying transport, but until now, it > hasn't > been a priority. > > hope this helps ... It all sounds reasonable. And since I'm not doing SSL at all in 1.0, it's not going to be an issue any time soon from my POV. Just wanted to make sure I was reading the spec right. Would it make sense for Mantara Elvin to accept ssl,none,xdr and ssl,tcp,xdr as equivalents in the meantime? Or has the "ssl" directive become tainted permanently with its hardcoding to TCP? Matt. From andrew at infradig.com Tue Apr 10 22:54:59 2007 From: andrew at infradig.com (Andrew Davison) Date: Tue Apr 10 22:55:14 2007 Subject: [elvin-discuss] missing specs Message-ID: <461C5C14.000001F5@infradig.com> So what's the word on the missing specs? draft-elvin-cluster-prelim-01.txt Cluster draft-elvin-federation-prelim-01.txt Federation draft-elvin-rlm-prelim-01.txt Reliable Local-area Multicast -------------- next part -------------- An HTML attachment was scrubbed... URL: http://laika.gnusto.com/pipermail/elvin-discuss/attachments/20070411/b2188c2c/attachment.htm From davida at pobox.com Tue Apr 10 23:08:20 2007 From: davida at pobox.com (David Arnold) Date: Tue Apr 10 23:08:29 2007 Subject: [elvin-discuss] missing specs In-Reply-To: Your message of "Wed, 11 Apr 2007 13:54:59 +1000." <461C5C14.000001F5@infradig.com> Message-ID: <4099.1176264500@d.0x1.org> -->"Andrew" == Andrew Davison writes: Andrew> So what's the word on the missing specs? Andrew> +------------------------------------------------------------------+ Andrew> |draft-elvin-cluster-prelim-01.txt |Cluster | Andrew> |------------------------------------+-----------------------------| Andrew> |draft-elvin-federation-prelim-01.txt|Federation | Andrew> |------------------------------------+-----------------------------| Andrew> |draft-elvin-rlm-prelim-01.txt |Reliable Local-area Multicast| Andrew> +------------------------------------------------------------------+ these protocols were developed by DSTC and then Mantara, who currently owns the source code in which they're embodied. their release is approved, but is subject to people with access to the source having the time to complete the existing documentation and push it out. the federation spec is the next priority, and i expect it'll be available (at least in a first draft) within in the next month. clustering and rlm are a lower priority: i'm not certain there's actually any real benefit in implementing them, but nominally they're on the to-do list. did you have a particular interest in these? thanks, d From david at mantara.com Sun Apr 15 22:12:20 2007 From: david at mantara.com (David Arnold) Date: Sun Apr 15 22:12:30 2007 Subject: [elvin-discuss] Re: Elvin spec In-Reply-To: Your message of "Mon, 08 Jan 2007 16:01:23 +1000." <20070105183046.X1229@trappist.lister.id.au> Message-ID: <27742.1176693140@d.0x1.org> -->"Ian" == Ian Lister writes: >>>> most important is the NACK code, i think. there's not much >>>> alternative for a client library than passing back a >>>> NOT_SUPPORTED to the application, but given it's allowable to >>>> have routers without quench, etc, it's gotta be reported somehow. >>> NO_ROUTER_SUPPORT, of course. If you got a NOT_SUPPORTED >>> (implying the lack of support is local) you'd just give up and go >>> home, but with NO_ROUTER_SUPPORT it's worth continuing to try >>> other routers. >> Not sure what the difference is? Either a request is recognised >> but not supported or it's a protocol violation surely? Ian> If the lack of support is local (e.g. your client library Ian> implementation doesn't support quench) there's no request at all. except that NO_ROUTER_SUPPORT and NOT_SUPPORTED are Mantara-specific, libelvin error codes, not protocol NACK error codes. in this case, i think the error should be treated similarly to a subscription language syntax error: the state machines are still in sync, it's just that a requested feature is unavailable from the current router. on that basis, i think error code 2007 would be appropriate? and, assuming existing client libraries are correctly implemented, they should cope nicely. >> But it's an opportunity to point out that I'm thinking that >> advertising the router using mDNS (Bonjour) might be a useful thing >> to do. Any opinions? Ian> Yes, Bonjour consists of IPv4LL (addressing), mDNS (naming) and Ian> DNS-SD (discovery). ERDP is the existing Elvin Router Discovery Ian> Protocol. IPv4LL is about automatic address assignment in the absence of a DHCP server. i think it's irrelevant to an Elvin router implemention. mDNS is multicast DNS resolution. in itself, i think it's irrelevant also (but see below). DNS-SD is the interesting bit of Bonjour as far as service discovery goes. IIRC (i haven't looked at it for a while), it uses a DNS name of the form _service._protocol.local to identify the target service, and mDNS resolve the query. i think the service bit uses the IANA-assigned name for the protocol. in the case of Elvin clients, that should be 'elvin_client' (although i *think* underscore is illegal in DNS names, so not sure what's going on there). the protocol bit should be '_tcp' for TCP-based services. this is all just my recollection. Stuart Cheshire has a fairly helpful web site for all the specs, links, etc. sorry for the delay in posting this: i just found the unsent draft :-( d From ilister at mantara.com Sun Apr 15 23:04:04 2007 From: ilister at mantara.com (Ian Lister) Date: Sun Apr 15 23:04:12 2007 Subject: [elvin-discuss] Re: Elvin spec In-Reply-To: <27742.1176693140@d.0x1.org> References: <27742.1176693140@d.0x1.org> Message-ID: <203F5E0A-2C9D-4A65-8EC4-A5934EDF7270@mantara.com> On 16/04/2007, at 1:12 PM, David Arnold wrote: > -->"Ian" == Ian Lister writes: [On 3 Jan 2007, David wrote:] >>>>> most important is the NACK code, i think. there's not much >>>>> alternative for a client library than passing back a >>>>> NOT_SUPPORTED to the application, but given it's allowable to >>>>> have routers without quench, etc, it's gotta be reported somehow. [On 5 Jan 2007, Ian wrote:] >>>> NO_ROUTER_SUPPORT, of course. If you got a NOT_SUPPORTED >>>> (implying the lack of support is local) you'd just give up and go >>>> home, but with NO_ROUTER_SUPPORT it's worth continuing to try >>>> other routers. [On 5 Jan 2007, Matthew wrote:] >>> Not sure what the difference is? Either a request is recognised >>> but not supported or it's a protocol violation surely? [On 8 Jan 2007, Ian wrote:] > Ian> If the lack of support is local (e.g. your client library > Ian> implementation doesn't support quench) there's no request at > all. > > except that NO_ROUTER_SUPPORT and NOT_SUPPORTED are Mantara-specific, > libelvin error codes, not protocol NACK error codes. I think we've already been through this in your mail of 11 Jan and my reply of the same day, but the point was that the reference to NOT_SUPPORTED (and, subsequently, NO_ROUTER_SUPPORT) was in the context of "a client library passing back a NOT_SUPPORTED to the application" i.e. an API level error code. This is of course all fairly tangential to the topic at hand, which was the protocol Nack code, but I believe you raised it in the paragraph at the top of this mail because the protocol needs to be able to identify the error specifically in order for the API to be able to. > in this case, i think the error should be treated similarly to a > subscription language syntax error: the state machines are still in > sync, it's just that a requested feature is unavailable from the > current > router. Yep. > on that basis, i think error code 2007 would be appropriate? and, > assuming existing client libraries are correctly implemented, they > should cope nicely. Yep. As per my reply to a subsequent email on 11 Jan in which you proposed this, I have no problem with that. > IPv4LL is about automatic address assignment in the absence of a DHCP > server. i think it's irrelevant to an Elvin router implemention. Yes. > mDNS is multicast DNS resolution. in itself, i think it's irrelevant > also (but see below). Yes. > DNS-SD is the interesting bit of Bonjour as far as service discovery > goes. IIRC (i haven't looked at it for a while), it uses a DNS > name of > the form _service._protocol.local to identify the target service, and > mDNS resolve the query. The .local suffix ties it to mDNS, but it is also designed to be used with existing domains and normal, unicast DNS. > i think the service bit uses the IANA-assigned name for the protocol. > in the case of Elvin clients, that should be > 'elvin_client' (although i > *think* underscore is illegal in DNS names, so not sure what's going > on there). It's illegal in host names and mail domains, but DNS itself is happy with just about anything as a label. > the protocol bit should be '_tcp' for TCP-based services. > > this is all just my recollection. > > Stuart Cheshire has a fairly helpful web site for all the specs, > links, > etc. And, for those interested, it's at: http://www.dns-sd.org/ Cheers, Ian From andrew at infradig.com Wed Apr 18 07:30:20 2007 From: andrew at infradig.com (Andrew Davison) Date: Wed Apr 18 07:31:05 2007 Subject: [elvin-discuss] I guess it works Message-ID: <46260F5D.000000E3@infradig.com> I guess the spec is sufficient, because I have a router implemented that works with Sticker clients. Minus keys for now (next to do) and quenches (sometime, ... later). A few double takes on some stuff but it all came clean in the wash. Can't believe I had to write yet another algebraic parser... god, how many is that now in 30 years of programming?. Thanks DA. Andrew From davida at pobox.com Wed Apr 18 19:44:57 2007 From: davida at pobox.com (David Arnold) Date: Wed Apr 18 19:45:07 2007 Subject: [elvin-discuss] I guess it works In-Reply-To: Your message of "Wed, 18 Apr 2007 22:30:20 +1000." <46260F5D.000000E3@infradig.com> Message-ID: <25372.1176943497@d.0x1.org> -->"Andrew" == Andrew Davison writes: hi Andrew, Andrew> I guess the spec is sufficient, because I have a router Andrew> implemented that works with Sticker clients. wow! that was fast! Andrew> Minus keys for now (next to do) and quenches (sometime, Andrew> ... later). yeah, that's the normal path of things :-) Andrew> A few double takes on some stuff but it all came clean in the Andrew> wash. anything in particular? i'd like to try to clarify anything that was obscure or under-specified, if possible. Andrew> Can't believe I had to write yet another algebraic Andrew> parser... god, how many is that now in 30 years of Andrew> programming? :-) Andrew> Thanks DA. no worries. so, now that you have one, what are your plans for it? would you like a link from the elvin.org pages for it? what language is it written in? there are various people who might be interested in such a beast, btw, depending on your plans ... d From scramjet at internode.on.net Thu Apr 19 11:22:29 2007 From: scramjet at internode.on.net (Matthew Phillips) Date: Thu Apr 19 11:22:47 2007 Subject: [elvin-discuss] I guess it works In-Reply-To: <25372.1176943497@d.0x1.org> References: <25372.1176943497@d.0x1.org> Message-ID: <94A4561D-1A5A-4A48-B1AF-8B815B39118F@internode.on.net> On 19/04/2007, at 10:14 AM, David Arnold wrote: > -->"Andrew" == Andrew Davison writes: > > hi Andrew, > > Andrew> I guess the spec is sufficient, because I have a router > Andrew> implemented that works with Sticker clients. > > wow! that was fast! As someone who's just been down that path, that was exactly my reaction too ;) > there are various people who might be interested in such a beast, btw, > depending on your plans ... And I also think we need a t-shirt with a slogan like: Yes, I wrote an Elvin router. What, hasn't everyone? Matt. From david at mantara.com Fri Apr 20 02:02:29 2007 From: david at mantara.com (David Arnold) Date: Fri Apr 20 02:02:37 2007 Subject: [elvin-discuss] Elvin Client Protocol 4.0 draft 6 Message-ID: <23197.1177052549@d.0x1.org> I've pushed draft -06 of the client protocol spec this afternoon. http://www.elvin.org/specs/draft-elvin-client-40-06.txt Changes are - added QosRqst/QosRply packet specification and some commentary. they were previously mentioned in a couple of places, but never actually defined. - fixed various references to subscription language function with underscores in their name rather than hyphens - added a description of the subscription language size() function All these issues were raised by Andrew Davison -- thanks Andrew! d From david at mantara.com Fri Apr 20 02:03:27 2007 From: david at mantara.com (David Arnold) Date: Fri Apr 20 02:03:31 2007 Subject: [elvin-discuss] list subscriptions Message-ID: <23204.1177052607@d.0x1.org> I notice that several people on the elvin-discuss list are not subscribed to elvin-announce. I've sent today's client spec revision announcement to both list, but in future I'd prefer not to double up. You can subscribe at http://www.elvin.org/lists.html Thanks, d From andrew at infradig.com Mon Apr 30 23:23:01 2007 From: andrew at infradig.com (Andrew Davison) Date: Mon Apr 30 23:25:05 2007 Subject: [elvin-discuss] UDP mode Message-ID: <4636C0A5.0000026E@infradigsystems.dyndns.org> Playing around in UDP mode and noticed that Sticker then does not bother with ConnRqst/DisconnRqst messages, just blindly starts adding subscriptions and doing notifies. Is this right? Andrew From david at mantara.com Mon Apr 30 23:57:52 2007 From: david at mantara.com (David Arnold) Date: Mon Apr 30 23:58:02 2007 Subject: [elvin-discuss] UDP mode In-Reply-To: Your message of "Tue, 01 May 2007 14:23:01 +1000." <4636C0A5.0000026E@infradigsystems.dyndns.org> Message-ID: <848.1177995472@d.0x1.org> -->"Andrew" == Andrew Davison writes: Andrew> Playing around in UDP mode and noticed that Sticker then does Andrew> not bother with ConnRqst/DisconnRqst messages, just blindly Andrew> starts adding subscriptions and doing notifies. Is this right? err, no. in terms of the abstract protocol: there is a UNotify packet, which is the only packet allowed to be used outside a logical connection established using ConnRqst/ConnRply. it is intended for extremely light-weight producers, such as environmental sensors, etc. you cannot use UNotify within an existing logical connection, and you cannot use subscriptions, quenches, TestConn/ConfConn, QosRqst/QosRply, SecRqst/SecRply, etc, without a logical connection. when a router accepts an incoming physical connection, it waits for either a ConnRqst, UNotify or a timeout. anything else should cause the physical connection to be dropped. channels can be established over any reliable, two-way transport. by default, this is TCP. the Mantara/DSTC code implements a fairly bogus UDP protocol module. it's bogus because it doesn't deal with dropped packets (and maybe not with packets larger than 64K?), and to safely implement the abstract protocol, it should. we have occasionally talked about a "udp2" protocol which addressed these failings, but it's never seemed worthwhile. i haven't seen the behaviour you describe from Sticker before. Sticker uses Mantara's Java-Elvin classes, so i'll take a look when i get a chance. d From andrew at infradig.com Tue May 1 00:32:45 2007 From: andrew at infradig.com (Andrew Davison) Date: Tue May 1 00:34:23 2007 Subject: [elvin-discuss] UDP mode In-Reply-To: <848.1177995472@d.0x1.org> References: <848.1177995472@d.0x1.org> Message-ID: <4636D0FD.0000029A@infradigsystems.dyndns.org> Thanks, that's what I thought. UDP is workable, though unreliable, as long as the client uses the same local port for sending throughout the session. It's a pity that NotifyEmit doesn't have a response and that NotifyDeliver doesn't have a sequence # per session. Andrew David Arnold wrote: > -->"Andrew" == Andrew Davison writes: > > Andrew> Playing around in UDP mode and noticed that Sticker then does > Andrew> not bother with ConnRqst/DisconnRqst messages, just blindly > Andrew> starts adding subscriptions and doing notifies. Is this right? > > err, no. > > in terms of the abstract protocol: > > there is a UNotify packet, which is the only packet allowed to be used > outside a logical connection established using ConnRqst/ConnRply. it is > intended for extremely light-weight producers, such as environmental > sensors, etc. > > you cannot use UNotify within an existing logical connection, and you > cannot use subscriptions, quenches, TestConn/ConfConn, QosRqst/QosRply, > SecRqst/SecRply, etc, without a logical connection. > > when a router accepts an incoming physical connection, it waits for > either a ConnRqst, UNotify or a timeout. anything else should cause the > physical connection to be dropped. > > > channels can be established over any reliable, two-way transport. by > default, this is TCP. > > the Mantara/DSTC code implements a fairly bogus UDP protocol module. > it's bogus because it doesn't deal with dropped packets (and maybe not > with packets larger than 64K?), and to safely implement the abstract > protocol, it should. > > we have occasionally talked about a "udp2" protocol which addressed > these failings, but it's never seemed worthwhile. > > > i haven't seen the behaviour you describe from Sticker before. Sticker > uses Mantara's Java-Elvin classes, so i'll take a look when i get a > chance. > > > > > > d > > > From andrew at infradig.com Tue May 1 01:07:13 2007 From: andrew at infradig.com (Andrew Davison) Date: Tue May 1 01:08:52 2007 Subject: [elvin-discuss] UDP mode In-Reply-To: <848.1177995472@d.0x1.org> References: <848.1177995472@d.0x1.org> Message-ID: <4636D911.000002AA@infradigsystems.dyndns.org> You might think i'm crazy, but it has stopped doing it. Sticker now sends an initial ConnRqst even in UDP mode, so don't bother looking into it. Andrew David Arnold wrote: > -->"Andrew" == Andrew Davison writes: > > Andrew> Playing around in UDP mode and noticed that Sticker then does > Andrew> not bother with ConnRqst/DisconnRqst messages, just blindly > Andrew> starts adding subscriptions and doing notifies. Is this right? > > err, no. > > in terms of the abstract protocol: > > there is a UNotify packet, which is the only packet allowed to be used > outside a logical connection established using ConnRqst/ConnRply. it is > intended for extremely light-weight producers, such as environmental > sensors, etc. > > you cannot use UNotify within an existing logical connection, and you > cannot use subscriptions, quenches, TestConn/ConfConn, QosRqst/QosRply, > SecRqst/SecRply, etc, without a logical connection. > > when a router accepts an incoming physical connection, it waits for > either a ConnRqst, UNotify or a timeout. anything else should cause the > physical connection to be dropped. > > > channels can be established over any reliable, two-way transport. by > default, this is TCP. > > the Mantara/DSTC code implements a fairly bogus UDP protocol module. > it's bogus because it doesn't deal with dropped packets (and maybe not > with packets larger than 64K?), and to safely implement the abstract > protocol, it should. > > we have occasionally talked about a "udp2" protocol which addressed > these failings, but it's never seemed worthwhile. > > > i haven't seen the behaviour you describe from Sticker before. Sticker > uses Mantara's Java-Elvin classes, so i'll take a look when i get a > chance. > > > > > > d > > > From andrew at infradig.com Tue May 1 01:27:39 2007 From: andrew at infradig.com (Andrew Davison) Date: Tue May 1 01:29:16 2007 Subject: [elvin-discuss] UDP mode In-Reply-To: <848.1177995472@d.0x1.org> References: <848.1177995472@d.0x1.org> Message-ID: <4636DDDC.000002B0@infradigsystems.dyndns.org> A 'udp2' that did framing would be fine. Like 'tcp' frames by prepending a packet length uint32, so 'udp2' could prepend a sequence nbr (a 'uint32' i guess) so lost packets could be at least notified to producer and consumer. A. David Arnold wrote: > we have occasionally talked about a "udp2" protocol which addressed > these failings, but it's never seemed worthwhile. > From andrew at arrivasoftware.com Wed May 2 21:46:32 2007 From: andrew at arrivasoftware.com (Andrew Davison) Date: Wed May 2 21:48:18 2007 Subject: [elvin-discuss] UDP mode In-Reply-To: <4636D911.000002AA@infradigsystems.dyndns.org> References: <848.1177995472@d.0x1.org> <4636D911.000002AA@infradigsystems.dyndns.org> Message-ID: <46394D08.0000004D@infradigsystems.dyndns.org> More on this UDP thing. When Sticker has encountered connection errors and you shut it down, it doesn't always seem to actually terminate, though the UI goes away. If you then run another instance it seems to think it's still connected so doesn't bother with the ConnRqst. Since then i've been always checking that the process really goes away (and killing it if it doesn't) and haven't had any problems. ad Andrew Davison wrote: > You might think i'm crazy, but it has stopped doing it. Sticker now > sends an initial ConnRqst even in UDP mode, so don't bother looking > into it. > > Andrew > > David Arnold wrote: >> -->"Andrew" == Andrew Davison writes: >> >> Andrew> Playing around in UDP mode and noticed that Sticker then does >> Andrew> not bother with ConnRqst/DisconnRqst messages, just blindly >> Andrew> starts adding subscriptions and doing notifies. Is this right? >> >> err, no. >> >> in terms of the abstract protocol: >> >> there is a UNotify packet, which is the only packet allowed to be used >> outside a logical connection established using ConnRqst/ConnRply. it is >> intended for extremely light-weight producers, such as environmental >> sensors, etc. >> >> you cannot use UNotify within an existing logical connection, and you >> cannot use subscriptions, quenches, TestConn/ConfConn, QosRqst/QosRply, >> SecRqst/SecRply, etc, without a logical connection. >> >> when a router accepts an incoming physical connection, it waits for >> either a ConnRqst, UNotify or a timeout. anything else should cause the >> physical connection to be dropped. >> >> >> channels can be established over any reliable, two-way transport. by >> default, this is TCP. >> >> the Mantara/DSTC code implements a fairly bogus UDP protocol module. >> it's bogus because it doesn't deal with dropped packets (and maybe not >> with packets larger than 64K?), and to safely implement the abstract >> protocol, it should. >> >> we have occasionally talked about a "udp2" protocol which addressed >> these failings, but it's never seemed worthwhile. >> >> >> i haven't seen the behaviour you describe from Sticker before. Sticker >> uses Mantara's Java-Elvin classes, so i'll take a look when i get a >> chance. >> >> >> >> >> >> d >> >> >> > > _______________________________________________ > elvin-discuss mailing list > elvin-discuss@elvin.org > http://www.elvin.org/mailman/listinfo/elvin-discuss From andrew at arrivasoftware.com Wed May 2 22:28:29 2007 From: andrew at arrivasoftware.com (Andrew Davison) Date: Wed May 2 22:30:12 2007 Subject: [elvin-discuss] UDP mode In-Reply-To: <46394D08.0000004D@infradigsystems.dyndns.org> References: <848.1177995472@d.0x1.org> <4636D911.000002AA@infradigsystems.dyndns.org> <46394D08.0000004D@infradigsystems.dyndns.org> Message-ID: <463956DE.00000069@infradigsystems.dyndns.org> Actually its probably just the old process still going thats doing it. ad Andrew Davison wrote: > More on this UDP thing. When Sticker has encountered connection errors > and you shut it down, it doesn't always seem to actually terminate, > though the UI goes away. If you then run another instance it seems to > think it's still connected so doesn't bother with the ConnRqst. Since > then i've been always checking that the process really goes away (and > killing it if it doesn't) and haven't had any problems. > > ad From david at mantara.com Tue May 15 21:00:37 2007 From: david at mantara.com (David Arnold) Date: Tue May 15 21:00:45 2007 Subject: [elvin-discuss] UDP mode In-Reply-To: Your message of "Tue, 01 May 2007 15:32:45 +1000." <4636D0FD.0000029A@infradigsystems.dyndns.org> Message-ID: <23812.1179280837@d.0x1.org> -->"Andrew" == Andrew Davison writes: Andrew> It's a pity that NotifyEmit doesn't have a response and that Andrew> NotifyDeliver doesn't have a sequence # per session. of course, a UDP-based protocol could do these fairly simply, but it's tricky to avoid reimplementing a poor-quality TCP. the major motivation for discussions of per-message sequence numbering has been for a multicast (rather than UDP-unicast) transport. those discussions have yet to produce anything tangible though ... d From andrew at arrivasoftware.com Tue May 15 21:25:57 2007 From: andrew at arrivasoftware.com (Andrew Davison) Date: Tue May 15 21:28:33 2007 Subject: [elvin-discuss] UDP mode In-Reply-To: <23812.1179280837@d.0x1.org> References: <23812.1179280837@d.0x1.org> Message-ID: <464A6BB5.0000027F@infradigsystems.dyndns.org> Thanks. I will only allow UDP for UNotify messages (and multicast) . Now SCTP would be a more viable alternative, if Windows supported it. Andrew David Arnold wrote: > -->"Andrew" == Andrew Davison writes: > > Andrew> It's a pity that NotifyEmit doesn't have a response and that > Andrew> NotifyDeliver doesn't have a sequence # per session. > > of course, a UDP-based protocol could do these fairly simply, but it's > tricky to avoid reimplementing a poor-quality TCP. > > the major motivation for discussions of per-message sequence numbering > has been for a multicast (rather than UDP-unicast) transport. those > discussions have yet to produce anything tangible though ... > > > > d > _______________________________________________ > elvin-discuss mailing list > elvin-discuss@elvin.org > http://www.elvin.org/mailman/listinfo/elvin-discuss > From andrew at arrivasoftware.com Fri May 18 18:49:55 2007 From: andrew at arrivasoftware.com (Andrew Davison) Date: Fri May 18 18:52:42 2007 Subject: [elvin-discuss] Arriva listed at elvin.org Message-ID: <464E3BA3.0000037B@infradigsystems.dyndns.org> David has kindly listed Arriva, my Elvin router implementation, at http://www.elvin.org in the implementations page. Currently a stand-alone router for WIN32 is available for download, and I hope to have a Linux release soon. There are no dependencies such as Java. And no client library is available as yet. It's definitely in the Beta release stage, so still probably bugs to iron out. Thanks. Andrew Davison http://www.arrivasoftware.com From andrew at arrivasoftware.com Mon Jun 18 20:33:07 2007 From: andrew at arrivasoftware.com (Andrew Davison) Date: Mon Jun 18 20:33:17 2007 Subject: [elvin-discuss] regex() function Message-ID: <46773253.000001B2@infradigsystems.dyndns.org> Is it meant to implement extended REs? I assume so. Andrew From davida at pobox.com Tue Jun 19 08:08:24 2007 From: davida at pobox.com (David Arnold) Date: Tue Jun 19 08:08:26 2007 Subject: [elvin-discuss] regex() function In-Reply-To: Your message of "Tue, 19 Jun 2007 11:33:07 +1000." <46773253.000001B2@infradigsystems.dyndns.org> Message-ID: <200706191308.l5JD8O4m006408@laika.gnusto.com> -->"Andrew" == Andrew Davison writes: Andrew> Is it meant to implement extended REs? I assume so. the historical statement has been that regex() should implement POSIX EREs for UTF-8 data. to be honest, i'm not sure if it's legitimate or sufficient to state the requirement so simply. i'll chase it up for the next spec revision. fwiw, Mantara's implementation does not quite fulfill that requirement, which you might keep in mind if you see any differences while testing. d From matt at mattp.name Sat Jul 7 20:44:39 2007 From: matt at mattp.name (Matthew Phillips) Date: Sat Jul 7 20:44:49 2007 Subject: [elvin-discuss] Some mention of Elvin and Avis in the blogosphere Message-ID: <8E199CD7-DB41-4518-8ADC-618563188335@mattp.name> Via my Google-filter: Planet Smalltalk, Sunday July 7: [Apologies if HTML email offends, but they don't seem to believe in permalinks, so I've copied the article here] """ Ian Cartwright has a post on rest, in particular http, not being the answer to all your problems. He touches on some alternatives (no, not WS-*!), but another post from April is interesting along the same lines: he wonders about reviving multicast on the internet, not just on a subnet. Which led to an interesting comment by Nat Pryce, that there are various internet multicast protocols, but anyway here's the interesting bits with some links included... Also, it turns out that it is easier to implement internet scale publish/subscribe event dissemination using an overlay network of reliable unicast links between routers and only use link-level multicast for the last hop, if at all. Have a look at Elvin, Avis and Siena, for example. Update: Good comments, and Nat provided the Avis link. """ Also, connected to that little micro-web was an interesting discussion on doing the Observer pattern in REST. Matt. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://laika.gnusto.com/pipermail/elvin-discuss/attachments/20070708/530ce5a1/attachment.htm From matt at mattp.name Sat Jul 7 21:00:29 2007 From: matt at mattp.name (Matthew Phillips) Date: Sat Jul 7 21:00:36 2007 Subject: [elvin-discuss] Avis and GPL 3 Message-ID: I'm planning to switch Avis to GPL v3 in the next release. I'd be interested in the opinions of anyone on list if they have any feelings pro or con. One small, but concrete advantage of v3 is that the LGPL is now just a set of exceptions to the GPL, rather than a separate license. Matt. From arnoldp at barfoo.net Mon Jul 9 01:34:53 2007 From: arnoldp at barfoo.net (Paul Arnold) Date: Wed Aug 8 10:07:37 2007 Subject: [elvin-discuss] QosRqst and QosRply missing in parts of the spec Message-ID: <4691D793.3080005@barfoo.net> Hi all, the 'Elvin Client Protocol 4.0 draft 6' spec appears to be missing references to QosRqst and QosRply in several places. In section 8.2.3.1, the pkt_id enumeration, no packet identification constants are specified for QosRqst or QosRply. What are the pkt_id constants for QosRqst and QosRply? Also, in section 7.1, the list of packet types, QosRqst and QosRply are missing. paul From phelps at mantara.com Wed Aug 8 18:15:46 2007 From: phelps at mantara.com (Ted Phelps) Date: Wed Aug 8 18:15:48 2007 Subject: [elvin-discuss] QosRqst and QosRply missing in parts of the spec In-Reply-To: Your message of Mon, 09 Jul 2007 06:37:07 GMT. <4691D793.3080005@barfoo.net> References: <4691D793.3080005@barfoo.net> Message-ID: <29003.1186614946@laika.gnusto.com> Hi Paul, Paul Arnold writes: > the 'Elvin Client Protocol 4.0 draft 6' spec appears to be missing > references to QosRqst and QosRply in several places. Oops. You are correct. Thanks for the feedback! > In section 8.2.3.1, the pkt_id enumeration, no packet identification > constants are specified for QosRqst or QosRply. What are the pkt_id > constants for QosRqst and QosRply? QosRqst is 70, QosRply is 71. I've updated the draft to reflect this. > Also, in section 7.1, the list of packet types, QosRqst and QosRply are > missing. Thanks. Also updated. Cheers, -Ted From matt at mattp.name Wed Aug 8 18:25:40 2007 From: matt at mattp.name (Matthew Phillips) Date: Wed Aug 8 18:25:44 2007 Subject: [elvin-discuss] QosRqst and QosRply missing in parts of the spec In-Reply-To: <4691D793.3080005@barfoo.net> References: <4691D793.3080005@barfoo.net> Message-ID: While we're picking holes in the spec, here are a couple of things I've noticed. I've mailed these to David separately, but either the email blocking issue we're having has got in the way, or he's avoiding me :) Matt. -- Client spec sec 8.2.3.4: * All the "tc_*" constants seem to be off by -1, at least against what the je4 API seems to think they are. * The fold-case and decompose ops seem to be missing. * "exists_tc" should be "require_tc"? * "equals_tc" is listed twice with different values. I assume one is "equals" and one is "=="? * There's a regular_expression_tc that seems to be a type that Elvin doesn't do anymore? Interesting historical artefact perhaps? From phelps at mantara.com Wed Aug 8 18:28:49 2007 From: phelps at mantara.com (Ted Phelps) Date: Wed Aug 8 18:28:50 2007 Subject: [elvin-discuss] QosRqst and QosRply missing in parts of the spec In-Reply-To: Your message of Thu, 09 Aug 2007 08:55:40 +0930. References: <4691D793.3080005@barfoo.net> Message-ID: <4994.1186615729@laika.gnusto.com> Matthew Phillips writes: > While we're picking holes in the spec, here are a couple of things > I've noticed. Thanks Matthew. This is useful feedback. > I've mailed these to David separately, but either the email blocking > issue we're having has got in the way, or he's avoiding me :) I suspect that David is simply stupidly overworked and hasn't gotten around to incorporating your changes. I'll try to get through them by Monday -- if you haven't heard from me by then then please hassle me further. :-) Thanks, -Ted From ilister at mantara.com Wed Aug 8 19:01:51 2007 From: ilister at mantara.com (Ian Lister) Date: Wed Aug 8 19:02:13 2007 Subject: [elvin-discuss] QosRqst and QosRply missing in parts of the spec In-Reply-To: <29003.1186614946@laika.gnusto.com> References: <4691D793.3080005@barfoo.net> <29003.1186614946@laika.gnusto.com> Message-ID: <227B56A0-1FE6-4A3F-A6CF-9FCA577BF5A1@mantara.com> I thought that QosRqst and QosRply didn't end up being part of the version 4.0 protocol? They weren't implemented in the Mantara Elvin C SDK or Router until the version 4.4 products in protocol 4.1, and I'm not aware of them being in any other protocol 4.0 implementation. FWIW there are even protocol 4.1 implementations that don't implement these packets, for example the Mantara Elvin C SDK and Router version 4.3 products. Cheers, Ian On 09/08/2007, at 9:15 AM, Ted Phelps wrote: > Hi Paul, > > Paul Arnold writes: >> the 'Elvin Client Protocol 4.0 draft 6' spec appears to be missing >> references to QosRqst and QosRply in several places. > > Oops. You are correct. Thanks for the feedback! > >> In section 8.2.3.1, the pkt_id enumeration, no packet identification >> constants are specified for QosRqst or QosRply. What are the pkt_id >> constants for QosRqst and QosRply? > > QosRqst is 70, QosRply is 71. I've updated the draft to reflect this. > >> Also, in section 7.1, the list of packet types, QosRqst and >> QosRply are >> missing. > > Thanks. Also updated. > > Cheers, > -Ted > _______________________________________________ > elvin-discuss mailing list > elvin-discuss@elvin.org > http://www.elvin.org/mailman/listinfo/elvin-discuss From matt at mattp.name Tue Aug 28 06:04:17 2007 From: matt at mattp.name (Matthew Phillips) Date: Tue Aug 28 06:04:23 2007 Subject: [elvin-discuss] Avis 1.1 Message-ID: <2DBA46CE-4956-4019-BCFA-184844422517@mattp.name> Hello all, you've probably seen this on freshmeat anyway, but I finally got Avis 1.1 out of the door yesterday. It's kind of a significant milestone for me for two reasons: (1) it supports federation, which is the last major thing I need at work in order to commence switch-over from Mantara Elvin and (2) it's now almost a year since I started work on Avis. To celebrate, I wrote a wikipedia page on Elvin (do I know how to party or what?) http://en.wikipedia.org/wiki/Elvin. It's not much, and to be honest I haven't looked closely enough at the wikipedia guidelines to know if it's even a good idea for the Elvin clan to edit it, but please let me know if you think it's good, bad or just plain ugly and I'll do my best to fix it. Thanks again to all that have provided feedback and help, much appreciated. Matt. From peizhao at itee.uq.edu.au Mon Sep 10 01:38:10 2007 From: peizhao at itee.uq.edu.au (Peizhao Hu) Date: Mon Sep 10 01:38:18 2007 Subject: [elvin-discuss] invalid object type for notification Message-ID: <46E4E652.9020102@itee.uq.edu.au> Hi All, What can I do to enable sending object notification? I tried with implements my class the Serializable interface, however, it still saying java.lang.IllegalArgumentException: invalid object type for notification any idea? -- regards; Peizhao From matt at mattp.name Mon Sep 10 03:43:17 2007 From: matt at mattp.name (Matthew Phillips) Date: Mon Sep 10 03:43:29 2007 Subject: [elvin-discuss] invalid object type for notification In-Reply-To: <46E4E652.9020102@itee.uq.edu.au> References: <46E4E652.9020102@itee.uq.edu.au> Message-ID: Hello Peizhao, you need to send the object as byte array. Serialise the object using a java.io.ObjectOutputStream connected to a java.io.ByteArrayOutputStream and then use that in the notification. Cheers, Matthew. On 10/09/2007, at 4:08 PM, Peizhao Hu wrote: > Hi All, > > What can I do to enable sending object notification? > I tried with implements my class the Serializable interface, > however, it still saying > java.lang.IllegalArgumentException: invalid object type for > notification > > any idea? > > -- > regards; > > Peizhao > _______________________________________________ > elvin-discuss mailing list > elvin-discuss@elvin.org > http://www.elvin.org/mailman/listinfo/elvin-discuss From whazlewo at indiana.edu Thu Oct 11 11:34:04 2007 From: whazlewo at indiana.edu (William R. Hazlewood) Date: Thu Oct 11 11:34:08 2007 Subject: [elvin-discuss] Hello All Message-ID: <470E507C.5040202@indiana.edu> I just joined the list, I've been using Elvin over the years, and to my surprise when i went to Mantara's webpage to download an update, boom, All the sudden the website is in New Jersey and my login does not work. I've been hunting around the web to try and figure out what happened. I guess mantara is no longer supporting elvin. luckily it looks like others are implementing the spec. I love this software and I hope it continues to exist. Did mantara own all the rights to the other API's they developed. I think I used to have access to a C API, JAVA API, .NET, PERL, PYTHON, etc. Is that all gone now? Is the leading implementation the Arriva one? In other words, if I want to implement a project using Elvin as the middleware, what do you recommend? Finally, Is Ted Phelps no longer involved at all? :-) He was a smart guy! Thanks in advance, Richie From whazlewo at indiana.edu Thu Oct 11 13:45:06 2007 From: whazlewo at indiana.edu (William R. Hazlewood) Date: Thu Oct 11 13:45:09 2007 Subject: [elvin-discuss] Old Mantara API's Message-ID: <470E6F32.8040100@indiana.edu> I have copies of the C-SDK and the .NET-SDK from Mantara still. I tested a simple app connecting to public.elvin.org with the .NET SDK and it worked swimmingly. Is this at all legit? From matt at mattp.name Thu Oct 11 18:24:12 2007 From: matt at mattp.name (Matthew Phillips) Date: Thu Oct 11 18:24:35 2007 Subject: [elvin-discuss] Hello All In-Reply-To: <470E507C.5040202@indiana.edu> References: <470E507C.5040202@indiana.edu> Message-ID: <6499D779-C1FB-46BC-8E47-4F553925795B@mattp.name> Hi Richie, I work for the Australian Department of Defence, and we too are quite fond of Elvin. I'll let the Mantara guys fill you in on what's going on with the company (I'd be interested in an update myself actually), but we are in the process of migrating from Mantara Elvin to Avis (http://avis.sourceforge.net). I developed Avis in response to the retirement of Elvin as a product and the perceived low probability that the new Mantara management would allow Elvin to be open sourced. Most of our projects build on the Java platform, so I've also developed a Java client API, and one of our partners (CSIRO) is in the process of developing a C++ API which will also be part of the Avis project. In terms of performance and reliability, all I can say is it's good enough for our needs and, since it's also being used by several of our partners, I can be fairly confident it will be a long-term option given the commitment we have to it. Cheers, Matthew. On 12/10/2007, at 2:04 AM, William R. Hazlewood wrote: > I just joined the list, I've been using Elvin over the years, and > to my surprise when i went to Mantara's webpage to download an > update, boom, All the sudden the website is in New Jersey and my > login does not work. > > I've been hunting around the web to try and figure out what > happened. I guess mantara is no longer supporting elvin. luckily it > looks like others are implementing the spec. I love this software > and I hope it continues to exist. > > Did mantara own all the rights to the other API's they developed. I > think I used to have access to a C API, JAVA API, .NET, PERL, > PYTHON, etc. Is that all gone now? > > > Is the leading implementation the Arriva one? In other words, if I > want to implement a project using Elvin as the middleware, what do > you recommend? > > > Finally, Is Ted Phelps no longer involved at all? :-) He was a > smart guy! > > Thanks in advance, > > > Richie > _______________________________________________ > elvin-discuss mailing list > elvin-discuss@elvin.org > http://www.elvin.org/mailman/listinfo/elvin-discuss From whazlewo at indiana.edu Fri Oct 12 10:34:49 2007 From: whazlewo at indiana.edu (William R. Hazlewood) Date: Fri Oct 12 10:34:54 2007 Subject: [elvin-discuss] Hello All In-Reply-To: <6499D779-C1FB-46BC-8E47-4F553925795B@mattp.name> References: <470E507C.5040202@indiana.edu> <6499D779-C1FB-46BC-8E47-4F553925795B@mattp.name> Message-ID: <470F9419.7040301@indiana.edu> I must say, if Mantara is going to be stingy, I'm awfully glad this new community is starting. I hope we can grow it somehow. I assume that since most have gone through the trials and tribulations of developing an Elvin protocol implementation already, the second iteration will just be that much better. I'll do my best to promote the technology, it's taken weeks and weeks off my project implementations in the past by letting me get several systems talking to one another. Of course I'd be willing to offer any feedback or assistance I can. I've written one tiny API, but thats just because I discovered PERL's InLine module, so it really just looked like an API :-). At our university we are building a "Living Lab" out of a small house on campus. The house will be heavily outfitted with different sensors. My plan was to just write an app that had each sensor as a producer on an elven server, and this would allow any students to have access to the sensor information. I wanted to do things in C# but I'll be just as happy in Java. I'll get this all set up with one of the other elvin implementations, and see if i can report on some of the going's on. I'd be happy to supply any sort of debugging info you need as well. Feeling Grateful, Richie Matthew Phillips wrote: > Hi Richie, > > I work for the Australian Department of Defence, and we too are quite > fond of Elvin. I'll let the Mantara guys fill you in on what's going on > with the company (I'd be interested in an update myself actually), but > we are in the process of migrating from Mantara Elvin to Avis > (http://avis.sourceforge.net). I developed Avis in response to the > retirement of Elvin as a product and the perceived low probability that > the new Mantara management would allow Elvin to be open sourced. > > Most of our projects build on the Java platform, so I've also developed > a Java client API, and one of our partners (CSIRO) is in the process of > developing a C++ API which will also be part of the Avis project. > > In terms of performance and reliability, all I can say is it's good > enough for our needs and, since it's also being used by several of our > partners, I can be fairly confident it will be a long-term option given > the commitment we have to it. > > Cheers, > > Matthew. > > On 12/10/2007, at 2:04 AM, William R. Hazlewood wrote: > >> I just joined the list, I've been using Elvin over the years, and to >> my surprise when i went to Mantara's webpage to download an update, >> boom, All the sudden the website is in New Jersey and my login does >> not work. >> >> I've been hunting around the web to try and figure out what happened. >> I guess mantara is no longer supporting elvin. luckily it looks like >> others are implementing the spec. I love this software and I hope it >> continues to exist. >> >> Did mantara own all the rights to the other API's they developed. I >> think I used to have access to a C API, JAVA API, .NET, PERL, PYTHON, >> etc. Is that all gone now? >> >> >> Is the leading implementation the Arriva one? In other words, if I >> want to implement a project using Elvin as the middleware, what do you >> recommend? >> >> >> Finally, Is Ted Phelps no longer involved at all? :-) He was a smart guy! >> >> Thanks in advance, >> >> >> Richie >> _______________________________________________ >> elvin-discuss mailing list >> elvin-discuss@elvin.org >> http://www.elvin.org/mailman/listinfo/elvin-discuss > From matt at mattp.name Sat Oct 13 00:35:27 2007 From: matt at mattp.name (Matthew Phillips) Date: Sat Oct 13 00:35:51 2007 Subject: [elvin-discuss] Hello All In-Reply-To: <470F9419.7040301@indiana.edu> References: <470E507C.5040202@indiana.edu> <6499D779-C1FB-46BC-8E47-4F553925795B@mattp.name> <470F9419.7040301@indiana.edu> Message-ID: <21101D3D-3EF7-47C8-A6EB-2C31D28649EB@mattp.name> On 13/10/2007, at 1:04 AM, William R. Hazlewood wrote: > At our university we are building a "Living Lab" out of a small > house on campus. The house will be heavily outfitted with > different sensors. My plan was to just write an app that had each > sensor as a producer on an elven server, and this would allow any > students to have access to the sensor information. I wanted to do > things in C# but I'll be just as happy in Java. I'll get this all > set up with one of the other elvin implementations, and see if i > can report on some of the going's on. I'd be happy to supply any > sort of debugging info you need as well. That would be great. It seems like a lot of the current users of Elvin are in universities. Which is a good thing, since it's a perfect fit for a lot of the projects students work on and can easily be extended into 'production' use. Will be interested to hear how you go - sensor data seems like another area that Elvin is well suited to. Feel free to ask any questions you may have. Matthew. > Matthew Phillips wrote: >> Hi Richie, >> I work for the Australian Department of Defence, and we too are >> quite fond of Elvin. I'll let the Mantara guys fill you in on >> what's going on with the company (I'd be interested in an update >> myself actually), but we are in the process of migrating from >> Mantara Elvin to Avis (http://avis.sourceforge.net). I developed >> Avis in response to the retirement of Elvin as a product and the >> perceived low probability that the new Mantara management would >> allow Elvin to be open sourced. >> Most of our projects build on the Java platform, so I've also >> developed a Java client API, and one of our partners (CSIRO) is in >> the process of developing a C++ API which will also be part of the >> Avis project. >> In terms of performance and reliability, all I can say is it's >> good enough for our needs and, since it's also being used by >> several of our partners, I can be fairly confident it will be a >> long-term option given the commitment we have to it. >> Cheers, >> Matthew. >> On 12/10/2007, at 2:04 AM, William R. Hazlewood wrote: >>> I just joined the list, I've been using Elvin over the years, and >>> to my surprise when i went to Mantara's webpage to download an >>> update, boom, All the sudden the website is in New Jersey and my >>> login does not work. >>> >>> I've been hunting around the web to try and figure out what >>> happened. I guess mantara is no longer supporting elvin. luckily >>> it looks like others are implementing the spec. I love this >>> software and I hope it continues to exist. >>> >>> Did mantara own all the rights to the other API's they developed. >>> I think I used to have access to a C API, JAVA API, .NET, PERL, >>> PYTHON, etc. Is that all gone now? >>> >>> >>> Is the leading implementation the Arriva one? In other words, if >>> I want to implement a project using Elvin as the middleware, what >>> do you recommend? >>> >>> >>> Finally, Is Ted Phelps no longer involved at all? :-) He was a >>> smart guy! >>> >>> Thanks in advance, >>> >>> >>> Richie >>> _______________________________________________ >>> elvin-discuss mailing list >>> elvin-discuss@elvin.org >>> http://www.elvin.org/mailman/listinfo/elvin-discuss