Menu
▾
▴
radioactive-developers — The RadioActive Project Developer Mailing List
You can subscribe to this list here.
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(30) |
Sep
(12) |
Oct
(11) |
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2006 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(6) |
Dec
(7) |
| 2007 |
Jan
(1) |
Feb
(1) |
Mar
(2) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(3) |
Aug
(3) |
Sep
(9) |
Oct
(8) |
Nov
(20) |
Dec
(35) |
| 2009 |
Jan
(10) |
Feb
(14) |
Mar
(14) |
Apr
(20) |
May
(32) |
Jun
(17) |
Jul
(29) |
Aug
(6) |
Sep
|
Oct
|
Nov
|
Dec
(7) |
| 2010 |
Jan
(9) |
Feb
(6) |
Mar
(3) |
Apr
(2) |
May
(1) |
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <sha...@ra...> - 2005-06-10 21:32:06
|
Hi everyone,=0D =0D I apologize for not getting this out earlier. I wanted to give you an upda= te on=0D the project from a project management stand point. As Michael mentioned in= his=0D email earlier in the week, the RadioActive project has officially become a = not=0D for profit foundation. As some of you who have talked with Somen or myself= over=0D the past 8 months you know that we believe there are many different softwar= e=0D applications that need to be developed as RFID and the EPC grow and mature.= As=0D the project was begging to gain IP we felt it necessary to have a legal ent= ity to=0D support it. The Apache Foundation closely resembled our idea of what Radio= Active=0D should be like, and we are modeling ourselves after them. Another note is = that=0D Michael Mealling has officially become a member of the project, although he= is=0D not new to helping us. Michael has been in contact with the RadioActive pr= oject=0D since day one and has probably logged more hours in the IRC channel than an= yone=0D to date. Somen and I are very excited to have him on board, officially.=0D =0D Currently there are three (3) projects on the go. These are Neutrino (EPC-= IS),=0D Fusion (ALE, middleware) and Graviton (Hardware simulator). Other ideas fo= r=0D projects we have include a hardware abstraction layer (like Hibernate, but = for=0D EPC related hardware) and a Commons project, which will include common comp= onents=0D all projects can share.=0D =0D For some of you who have been paying attention since we started the project= =0D roughly 8 months ago it may appear that the project was dead for a while. = I=0D assure you, that although there has not been any major releases, we have=0D continued to work on the project from a research stand point, as well as tr= ying=0D to meet as many people in the industry that were willing to help us with ad= vice,=0D and potentially development resources. All of this has continued to happen= in=0D our part time like many traditional open source projects, and has been quit= e a=0D challenge that we are finally getting a grip on.=0D =0D The foundation will be overseen by a consortium of individuals and organiza= tions.=0D There will be two levels of participation in the project. One level is a= =0D =93volunteer=94 and the other level is a =93member=94. A volunteer will ge= nerally be=0D individuals that have an interest in the technology for personal and career= =0D motives. If you are looking for experience or trying to build your resume = out of=0D school, you probably fit into this category. Members are usually organizat= ions=0D that have an interest in using pieces of software from the foundation and w= ant to=0D over see its development and have a personal stake in its growth. This is = just a=0D rough outline of the structure of the Foundation. I have been working off = bylaws=0D that are very similar to the Apache bylaws and should have them posted on t= he=0D site soon. These will explain the structure and the roles in the foundatio= n.=0D =0D This is already too long. We will keep you posted, and feel free to contac= t us=0D with any questions.=0D =0D Thanks,=0D Shaun=0D =0D |
|
From: Shah, S. <Sap...@pa...> - 2005-06-10 19:43:57
|
SSBiZWxpZXZlLCB3ZSBzaG91bGQgaGF2ZSBhIGNhbGwsIGlmIGl0IG1ha2Ug c2Vuc2Ugc28gdGhhdCB3ZSBhbGwgY2FuIGdldCBvbiB0aGUgc2FtZSBwYWdl IGZvciB0aGUgYWN0aXZpdGllcyBnb2luZyBvbi4NCiANCkFueSB0aG91Z2h0 cz8NCiANClNhcGFuDQogDQoNCgktLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LSANCglGcm9tOiByYWRpb2FjdGl2ZS1kZXNpZ24tYWRtaW5AbGlzdHMuc291 cmNlZm9yZ2UubmV0IG9uIGJlaGFsZiBvZiBNaWNoYWVsIE1lYWxsaW5nIA0K CVNlbnQ6IFR1ZSA2LzcvMjAwNSAyOjQzIFBNIA0KCVRvOiByYWRpb2FjdGl2 ZS1kZXZlbG9wZXJzQGxpc3RzLnNvdXJjZWZvcmdlLm5ldDsgcmFkaW9hY3Rp dmUtZGVzaWduQGxpc3RzLnNvdXJjZWZvcmdlLm5ldCANCglDYzogDQoJU3Vi amVjdDogW1JhZGlvYWN0aXZlLWRlc2lnbl0gUmVjZW50IHByb2plY3QgYW5u b3VuY2VtZW50cywgdGhlIEZvdW5kYXRpb24gYW5kIG90aGVyIG5ld3MuLi4u DQoJDQoJDQoNCglIaSBldmVyeW9uZSwNCgkgIEFzIHNvbWUgb2YgeW91IG1p Z2h0IGhhdmUgc2VlbiwgdGhlIGxhc3Qgd2VlayBoYXMgYmVlbiBhIGJ1c3kg b25lIGZvcg0KCXRoZSBwcm9qZWN0LiBUaGUgZm91bmRlcnMgaGF2ZSBzZXR1 cCBhIG5vbi1wcm9maXQgZm91bmRhdGlvbiBpbiBvcmRlciB0bw0KCWdpdmUg dGhlIHByb2plY3QgYSBsZWdhbCBmb290aW5nIChtb3JlIG9uIHRoYXQgZnJv bSBTb21lbiBhbmQgU2hhdW4NCglsYXRlciksIGFuZCBkdWUgdG8gc29tZSBy ZWNlbnQgYW5kIHByb3Bvc2VkIGNvZGUgZG9uYXRpb25zIHdlJ3ZlDQoJZXhw YW5kZWQgdGhlIHNjb3BlIGEgYml0IHRvIGluY2x1ZGUgb3RoZXIgcGFydHMg b2YgdGhlIEVQQ2dsb2JhbA0KCWFyY2hpdGVjdHVyZS4gU3BlY2lmaWNhbGx5 IHRoZSBleGlzdGluZyBtaWRkbGV3YXJlIHByb2plY3QgaXMgam9pbmVkIGJ5 DQoJdGhlIE5ldXRyaW5vIGFuZCBHcmF2aXRvbiBwcm9qZWN0cy4gVGhlIE5l dXRyaW5vIHByb2plY3QgaXMgYWJvdXQgdGhlDQoJcGFydCBvZiB0aGUgYXJj aGl0ZWN0dXJlIHRoYXQgaGFuZGxlcyB0aGUgZGF0YSBjb21tdW5pY2F0aW9u cyBiZXR3ZWVuDQoJZW50ZXJwcmlzZXMgYW5kIGluY2x1ZGVzIHRoaW5ncyBz dWNoIGFzIGFuIE9OUyBjbGllbnQgYW5kIGFuIEVQQy1JUw0KCXNlcnZlci4g VGhlIEdyYXZpdG9uIHByb2plY3QgaW5jbHVkZXMgdGhlIHhTaW0gcHJvamVj dCBwbHVzIGV2ZW50dWFsDQoJaW1wbGVtZW50YXRpb25zIG9mIHRoZSB2YXJp b3VzIHJlYWRlciBwcm90b2NvbHMgYW5kIHJlYWRlciBtYW5hZ2VtZW50DQoJ c3RhbmRhcmRzLiBIZXJlJ3MgYSByb2FkIG1hcCBzaG93aW5nIGhvdyB0aGV5 IHJlbGF0ZSBhbmQgdGhlIGdlbmVyYWwNCglFUENnbG9iYWwgTmV0d29yayBh cmNoaXRlY3R1cmU6IGh0dHA6Ly9yYWRpb2FjdGl2ZWhxLm9yZy9yb2FkbWFw Lmh0bWwNCgkgIE9uZSBwcm9qZWN0IHRoYXQgaXNuJ3Qgb24gdGhlcmUgdGhh dCBwcm9iYWJseSBzaG91bGQgZXhpc3QgaXMgd2hhdCBJDQoJY2FsbCB0aGUg Q29tbW9ucyAodGhhdCdzIHdoYXQgdGhlIEFwYWNoZSBndXlzIGNhbGwgdGhl aXIncykuIFRoYXQncw0KCW1vc3RseSBsaWJyYXJpZXMgYW5kIHV0aWxpdGll cyB0aGF0IGFsbCBvZiB0aGUgb3RoZXIgcHJvamVjdHMgbmVlZC4gSXQNCgl3 b3VsZCBpbmNsdWRlIHRoaW5ncyBsaWtlIHRhZyBwYXJzaW5nLCB0YWcgdHJh bnNsYXRpb24sIHNlY3VyaXR5LCBldGMuIEkNCgloYXZlIGFscmVhZHkgZG9u YXRlZCBhIGdvb2QgYml0IG9mIHRoZSB0YWcgcmVsYXRlZCBjb2RlIGZyb20g bXkgb2xkDQoJeGNFUEMgcHJvamVjdCBhbmQgd2lsbCBiZSByZWZhY3Rvcmlu ZyB0aGF0IHRvIHJlZmxlY3QgdGhlIHByb2plY3Qncw0KCXBhY2thZ2Ugc3Ry dWN0dXJlIHNvb24uIEl0cyBhbGwgaW4gdGhlIGN1cnJlbnQgcHJvamVjdCBD VlMgdW5kZXIgdGhlDQoJY29tbW9ucyBkaXJlY3RvcnkuDQoJICBTbyBpZiB5 b3UncmUgb25seSBpbnRlcmVzdGVkIGluIHRoZSBtaWRkbHdhcmUgd29yayB0 aGF0J3MgYWxyZWFkeSBiZWVuDQoJc3RhcnRlZCB0aGVuIG5vdGhpbmcgcmVh bGx5IGNoYW5nZXMgZXhjZXB0IHRoZSBuYW1lLiBCdXQgaWYgYW55b25lIGlz DQoJaW50ZXJlc3RlZCBpbiBoZWxwaW5nIG91dCB3aXRoIHRoZSBOZXV0cmlu byBhbmQvb3IgR3Jhdml0b24gcGFydHMgdGhlbg0KCXRoZXJlIHNob3VsZCBi ZSBhIHByb2plY3QgaW5mcmFzdHJ1Y3R1cmUgZm9ybWluZyBhcm91bmQgdGhv c2Ugc29vbi4gSQ0KCXN1c3BlY3QgdGhhdCBnaXZlbiBTb3VyY2Vmb3JnZSdz IHN0cnVjdHVyZSB0aG9zZSB3aWxsIGJlIHNlcGFyYXRlDQoJU291cmNlZm9y Z2UgcHJvamVjdHMgdW5sZXNzIHNvbWVvbmUgaGFzIGEgYmV0dGVyIG9yZ2Fu aXphdGlvbmFsDQoJc3VnZ2VzdGlvbi4NCgkgIEkndmUgc2VudCB0aGlzIHRv IHRoZSBkZXNpZ24gYW5kIGRldmVsb3BlcnMgbGlzdHMgdG8gbWFrZSBzdXJl IEkgaGl0DQoJZXZlcnlvbmUgYnV0IEknZCBsaWtlIHRvIGtlZXAgdGhlIGdl bmVyYWwgYXJjaGl0ZWN0dXJlIGRpc2N1c3Npb24gdG8gdGhlDQoJZGVzaWdu IGxpc3QganVzdCB0byBrZWVwIGl0IGFsbCBmb2N1c2VkLg0KCQ0KCS1NTQ0K CQ0KCS0tDQoJTWljaGFlbCBNZWFsbGluZyAgICAgICAgICAgICAgICAgICAg ICAgICBSZWZhY3RvcmVkIE5ldHdvcmtzLCBMTEMNCglDRU8gJiBQcmVzaWRl bnQgICAgICAgICAgICAgICAgICAgICAgICAgIDE2NDUgT2xkIEh3eSA0MQ0K CU9mZmljZTogKzEtNjc4LTU4MS05NjU2ICAgICAgICAgICAgICAgICAgU3Vp dGUgMTEyLCBCb3ggMTM4DQoJQ2VsbDogKzEtNjc4LTY0MC02ODg0ICAgICAg ICAgICAgICAgICAgICBLZW5uZXNhdywgR0EgMzAxNTINCgkgICAgICAgICAg ICAgICBodHRwOi8vcmVmYWN0b3JlZC1uZXR3b3Jrcy5jb20vDQoJDQoJDQoJ DQoJDQoJLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KCVRoaXMgU0YuTmV0IGVtYWlsIGlzIHNwb25z b3JlZCBieTogTkVDIElUIEd1eSBHYW1lcy4gIEhvdyBmYXIgY2FuIHlvdSBz aG90cHV0DQoJYSBwcm9qZWN0b3I/IEhvdyBmYXN0IGNhbiB5b3UgcmlkZSB5 b3VyIGRlc2sgY2hhaXIgZG93biB0aGUgb2ZmaWNlIGx1Z2UgdHJhY2s/DQoJ SWYgeW91IHdhbnQgdG8gc2NvcmUgdGhlIGJpZyBwcml6ZSwgZ2V0IHRvIGtu b3cgdGhlIGxpdHRsZSBndXkuIA0KCVBsYXkgdG8gd2luIGFuIE5FQyA2MSIg cGxhc21hIGRpc3BsYXk6IGh0dHA6Ly93d3cubmVjaXRndXkuY29tLz9yPTIw DQoJX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCglSYWRpb2FjdGl2ZS1kZXNpZ24gbWFpbGluZyBsaXN0DQoJUmFk aW9hY3RpdmUtZGVzaWduQGxpc3RzLnNvdXJjZWZvcmdlLm5ldA0KCWh0dHBz Oi8vbGlzdHMuc291cmNlZm9yZ2UubmV0L2xpc3RzL2xpc3RpbmZvL3JhZGlv YWN0aXZlLWRlc2lnbg0KCQ0KDQoKaHR0cDovL3d3dy5wYXRuaS5jb20KV29y bGQtV2lkZSBQYXJ0bmVyc2hpcHMuIFdvcmxkLUNsYXNzIFNvbHV0aW9ucy4K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fCgpUaGlzIGUtbWFpbCBtZXNzYWdl IG1heSBjb250YWluIHByb3ByaWV0YXJ5LCBjb25maWRlbnRpYWwgb3IgbGVn YWxseQpwcml2aWxlZ2VkIGluZm9ybWF0aW9uIGZvciB0aGUgc29sZSB1c2Ug b2YgdGhlIHBlcnNvbiBvciBlbnRpdHkgdG8Kd2hvbSB0aGlzIG1lc3NhZ2Ug d2FzIG9yaWdpbmFsbHkgYWRkcmVzc2VkLiBBbnkgcmV2aWV3LCBlLXRyYW5z bWlzc2lvbgpkaXNzZW1pbmF0aW9uIG9yIG90aGVyIHVzZSBvZiBvciB0YWtp bmcgb2YgYW55IGFjdGlvbiBpbiByZWxpYW5jZSB1cG9uCnRoaXMgaW5mb3Jt YXRpb24gYnkgcGVyc29ucyBvciBlbnRpdGllcyBvdGhlciB0aGFuIHRoZSBp bnRlbmRlZApyZWNpcGllbnQgaXMgcHJvaGliaXRlZC4gSWYgeW91IGhhdmUg cmVjZWl2ZWQgdGhpcyBlLW1haWwgaW4gZXJyb3IKa2luZGx5IGRlbGV0ZSAg dGhpcyBlLW1haWwgZnJvbSB5b3VyIHJlY29yZHMuIElmIGl0IGFwcGVhcnMg dGhhdCB0aGlzCm1haWwgaGFzIGJlZW4gZm9yd2FyZGVkIHRvIHlvdSB3aXRo b3V0IHByb3BlciBhdXRob3JpdHksIHBsZWFzZSBub3RpZnkKdXMgaW1tZWRp YXRlbHkgYXQgbmV0YWRtaW5AcGF0bmkuY29tIGFuZCBkZWxldGUgdGhpcyBt YWlsLiAKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCg== |
|
From: Michael M. <mi...@re...> - 2005-06-07 18:43:29
|
Hi everyone, As some of you might have seen, the last week has been a busy one for the project. The founders have setup a non-profit foundation in order to give the project a legal footing (more on that from Somen and Shaun later), and due to some recent and proposed code donations we've expanded the scope a bit to include other parts of the EPCglobal architecture. Specifically the existing middleware project is joined by the Neutrino and Graviton projects. The Neutrino project is about the part of the architecture that handles the data communications between enterprises and includes things such as an ONS client and an EPC-IS server. The Graviton project includes the xSim project plus eventual implementations of the various reader protocols and reader management standards. Here's a road map showing how they relate and the general EPCglobal Network architecture: http://radioactivehq.org/roadmap.html One project that isn't on there that probably should exist is what I call the Commons (that's what the Apache guys call their's). That's mostly libraries and utilities that all of the other projects need. It would include things like tag parsing, tag translation, security, etc. I have already donated a good bit of the tag related code from my old xcEPC project and will be refactoring that to reflect the project's package structure soon. Its all in the current project CVS under the commons directory. So if you're only interested in the middlware work that's already been started then nothing really changes except the name. But if anyone is interested in helping out with the Neutrino and/or Graviton parts then there should be a project infrastructure forming around those soon. I suspect that given Sourceforge's structure those will be separate Sourceforge projects unless someone has a better organizational suggestion. I've sent this to the design and developers lists to make sure I hit everyone but I'd like to keep the general architecture discussion to the design list just to keep it all focused. -MM -- Michael Mealling Refactored Networks, LLC CEO & President 1645 Old Hwy 41 Office: +1-678-581-9656 Suite 112, Box 138 Cell: +1-678-640-6884 Kennesaw, GA 30152 http://refactored-networks.com/ |
|
From: bala.bandla <bal...@ca...> - 2005-01-07 10:08:15
|
Hi, I have just started working on RFID project. My first assignment is to create a simulator in java that will mimic the most common RFID readers. We want to use this emulator for testing the other components like the middleware Thanks |
|
From: Somen M. <som...@ra...> - 2004-10-05 00:13:37
|
HI Felipe, To my knowledge, there will be no PML replacement. But if there was, it would be lead by the EPCGlobal. Perhaps some of our members closer to = the EPC board could shed some light into this issue. =20 Thanks, Somen -----Original Message----- From: rad...@li... [mailto:rad...@li...] On Behalf Of Felipe Nascimento Sent: Monday, October 04, 2004 9:50 AM To: 'Somen Mondal'; rad...@li... Subject: RE: [Radioactive-developers] RE: Status Hi Somen, That helped, yes.=20 My dissertation is changing a little as I see too little has been done = on lower level issues. So, if I wanted to track and trace medications along = the supply chain, now I see I need to first track and trace products inside = "my own organization". So that means doing what you said: having n = distributed middlewares with m readers each one, tracking EPCs along the = organization, talking to each other (some Multi-Agent Systems characteristics). I'll definitely do something about this. Maybe in the near future I can help = you guys whit some things I'll have done... For the data being transferred in an XML format, is there a definition = on that dtd? If PML no longer exist, is there aynthing substituting it, I = mean is EPCglobal leading this also, or will be no standards on this issue? Tks again Felipe -----Original Message----- From: Somen Mondal [mailto:som...@ra...]=20 Sent: s=E1bado, 2 de outubro de 2004 18:29 To: 'Felipe Nascimento'; rad...@li... Subject: RE: [Radioactive-developers] RE: Status Hi Felipe, When you say delete EPC, you can never really delete an epc. Perhaps = you meant left the range of a reader? I agree with you, the middleware does raise events and clients can subscribe to these events (ALE). I = middleware can be configured to raise any kind of events that we see fit. There is = no specification, so its up to us. =20 The middleware should keep track of all the readers connected to it. = The middleware will keep track of all the events across all the readers, so = if one reader detects an epc and then "deletes" it, the middleware will = sense when the next reader gets the epc signal and keep track of it. I think your assuming that that relationship of reader to middleware = will be one to one. There can be many readers for one middleware instance. = Right now, we are dealing with one instance of the middleware, but, in the = future we could have multiple instances of the middleware where we would either have to have some sort of distributed system and have all the middleware instances talk to each other OR have it done at the higher levels. We = could basically have a client subscribe to each middleware instance = individually. But this is something for down the road. Shaun and I had discussed a distributed style middleware based on nodes where all clients would only ever talk to a super node. This is a definite possibility. =20 All communication for now will use JMS and http(web services).. For = data, we'll always use an XML format. PML no longer exists really, but = something similar. Hope that helps, Somen -----Original Message----- From: rad...@li... [mailto:rad...@li...] On Behalf Of Felipe Nascimento Sent: Friday, October 01, 2004 5:37 PM To: rad...@li... Subject: RE: [Radioactive-developers] RE: Status Hi guys, the middleware receive reads from a reader (or more than one) and can = raise events, right? The most low level events I can think of are: a) added EPC; b) deleted EPC (when an epc was there and is not anymore) Will the middleware raise deletion events? If yes, will the middleware = treat cases when an EPC was deleted from one reader and added to another? Or = this is a higher level application responsibility? What are your thoughts about these raising events? Will different = instances of middleware talk to each other, maybe to detect an EPC has moved? Or = again this is a higher level app responsibility? How will events be raised, in terms of message format and protocol? PML = and SOAP? JMS? This is important for me so I can visualize if I need to develop those deletion, movement, etc, functionalities in my application, or I should contribute to RadioActive, maybe in this ALE module (I believe these = would be ALE's funcionalities). Tks Felipe ________________________________ From: rad...@li... [mailto:rad...@li...] On Behalf Of Somen Mondal Sent: quinta-feira, 30 de setembro de 2004 23:13 To: rad...@li...; rad...@li... Subject: [Radioactive-developers] RE: Status Hi Guys, =20 Just wanted to give you the status of our project. =20 We are currently developing 3 pieces of software: =20 1) the EPC-IS prototype 2) the middleware 3) a hardware simulator =20 Randy is heading up the hardware simulator, and our goal is to have a = driver interface to simulate different readers and to generate the reader's = network traffic. Shaun, Pawel and I are developing the base EPC-IS and = middleware. Once we have the base, it will be easier for more people to help develop = the rest. =20 =20 I really think our prototype software is going to get pretty complicated = and can probably be a release 0.1.=20 =20 Thanks, Somen ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal = Use IT products in your business? Tell us what you think of them. Give us = Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Radioactive-developers mailing list Rad...@li... https://lists.sourceforge.net/lists/listinfo/radioactive-developers ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give = us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out = more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Radioactive-developers mailing list Rad...@li... https://lists.sourceforge.net/lists/listinfo/radioactive-developers |
|
From: Felipe N. <fel...@in...> - 2004-10-04 13:43:40
|
Hi Somen, That helped, yes.=20 My dissertation is changing a little as I see too little has been done = on lower level issues. So, if I wanted to track and trace medications along = the supply chain, now I see I need to first track and trace products inside = "my own organization". So that means doing what you said: having n = distributed middlewares with m readers each one, tracking EPCs along the = organization, talking to each other (some Multi-Agent Systems characteristics). I'll definitely do something about this. Maybe in the near future I can help = you guys whit some things I'll have done... For the data being transferred in an XML format, is there a definition = on that dtd? If PML no longer exist, is there aynthing substituting it, I = mean is EPCglobal leading this also, or will be no standards on this issue? Tks again Felipe -----Original Message----- From: Somen Mondal [mailto:som...@ra...]=20 Sent: s=E1bado, 2 de outubro de 2004 18:29 To: 'Felipe Nascimento'; rad...@li... Subject: RE: [Radioactive-developers] RE: Status Hi Felipe, When you say delete EPC, you can never really delete an epc. Perhaps = you meant left the range of a reader? I agree with you, the middleware does raise events and clients can subscribe to these events (ALE). I = middleware can be configured to raise any kind of events that we see fit. There is = no specification, so its up to us. =20 The middleware should keep track of all the readers connected to it. = The middleware will keep track of all the events across all the readers, so = if one reader detects an epc and then "deletes" it, the middleware will = sense when the next reader gets the epc signal and keep track of it. I think your assuming that that relationship of reader to middleware = will be one to one. There can be many readers for one middleware instance. = Right now, we are dealing with one instance of the middleware, but, in the = future we could have multiple instances of the middleware where we would either have to have some sort of distributed system and have all the middleware instances talk to each other OR have it done at the higher levels. We = could basically have a client subscribe to each middleware instance = individually. But this is something for down the road. Shaun and I had discussed a distributed style middleware based on nodes where all clients would only ever talk to a super node. This is a definite possibility. =20 All communication for now will use JMS and http(web services).. For = data, we'll always use an XML format. PML no longer exists really, but = something similar. Hope that helps, Somen -----Original Message----- From: rad...@li... [mailto:rad...@li...] On Behalf Of Felipe Nascimento Sent: Friday, October 01, 2004 5:37 PM To: rad...@li... Subject: RE: [Radioactive-developers] RE: Status Hi guys, the middleware receive reads from a reader (or more than one) and can = raise events, right? The most low level events I can think of are: a) added EPC; b) deleted EPC (when an epc was there and is not anymore) Will the middleware raise deletion events? If yes, will the middleware = treat cases when an EPC was deleted from one reader and added to another? Or = this is a higher level application responsibility? What are your thoughts about these raising events? Will different = instances of middleware talk to each other, maybe to detect an EPC has moved? Or = again this is a higher level app responsibility? How will events be raised, in terms of message format and protocol? PML = and SOAP? JMS? This is important for me so I can visualize if I need to develop those deletion, movement, etc, functionalities in my application, or I should contribute to RadioActive, maybe in this ALE module (I believe these = would be ALE's funcionalities). Tks Felipe ________________________________ From: rad...@li... [mailto:rad...@li...] On Behalf Of Somen Mondal Sent: quinta-feira, 30 de setembro de 2004 23:13 To: rad...@li...; rad...@li... Subject: [Radioactive-developers] RE: Status Hi Guys, =20 Just wanted to give you the status of our project. =20 We are currently developing 3 pieces of software: =20 1) the EPC-IS prototype 2) the middleware 3) a hardware simulator =20 Randy is heading up the hardware simulator, and our goal is to have a = driver interface to simulate different readers and to generate the reader's = network traffic. Shaun, Pawel and I are developing the base EPC-IS and = middleware. Once we have the base, it will be easier for more people to help develop = the rest. =20 =20 I really think our prototype software is going to get pretty complicated = and can probably be a release 0.1.=20 =20 Thanks, Somen ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal = Use IT products in your business? Tell us what you think of them. Give us = Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Radioactive-developers mailing list Rad...@li... https://lists.sourceforge.net/lists/listinfo/radioactive-developers |
|
From: Somen M. <som...@ra...> - 2004-10-02 22:02:35
|
Hi Felipe, When you say delete EPC, you can never really delete an epc. Perhaps you meant left the range of a reader? I agree with you, the middleware does raise events and clients can subscribe to these events (ALE). I middleware can be configured to raise any kind of events that we see fit. There is no specification, so its up to us. The middleware should keep track of all the readers connected to it. The middleware will keep track of all the events across all the readers, so if one reader detects an epc and then "deletes" it, the middleware will sense when the next reader gets the epc signal and keep track of it. I think your assuming that that relationship of reader to middleware will be one to one. There can be many readers for one middleware instance. Right now, we are dealing with one instance of the middleware, but, in the future we could have multiple instances of the middleware where we would either have to have some sort of distributed system and have all the middleware instances talk to each other OR have it done at the higher levels. We could basically have a client subscribe to each middleware instance individually. But this is something for down the road. Shaun and I had discussed a distributed style middleware based on nodes where all clients would only ever talk to a super node. This is a definite possibility. All communication for now will use JMS and http(web services).. For data, we'll always use an XML format. PML no longer exists really, but something similar. Hope that helps, Somen -----Original Message----- From: rad...@li... [mailto:rad...@li...] On Behalf Of Felipe Nascimento Sent: Friday, October 01, 2004 5:37 PM To: rad...@li... Subject: RE: [Radioactive-developers] RE: Status Hi guys, the middleware receive reads from a reader (or more than one) and can raise events, right? The most low level events I can think of are: a) added EPC; b) deleted EPC (when an epc was there and is not anymore) Will the middleware raise deletion events? If yes, will the middleware treat cases when an EPC was deleted from one reader and added to another? Or this is a higher level application responsibility? What are your thoughts about these raising events? Will different instances of middleware talk to each other, maybe to detect an EPC has moved? Or again this is a higher level app responsibility? How will events be raised, in terms of message format and protocol? PML and SOAP? JMS? This is important for me so I can visualize if I need to develop those deletion, movement, etc, functionalities in my application, or I should contribute to RadioActive, maybe in this ALE module (I believe these would be ALE's funcionalities). Tks Felipe ________________________________ From: rad...@li... [mailto:rad...@li...] On Behalf Of Somen Mondal Sent: quinta-feira, 30 de setembro de 2004 23:13 To: rad...@li...; rad...@li... Subject: [Radioactive-developers] RE: Status Hi Guys, Just wanted to give you the status of our project. We are currently developing 3 pieces of software: 1) the EPC-IS prototype 2) the middleware 3) a hardware simulator Randy is heading up the hardware simulator, and our goal is to have a driver interface to simulate different readers and to generate the reader's network traffic. Shaun, Pawel and I are developing the base EPC-IS and middleware. Once we have the base, it will be easier for more people to help develop the rest. I really think our prototype software is going to get pretty complicated and can probably be a release 0.1. Thanks, Somen ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Radioactive-developers mailing list Rad...@li... https://lists.sourceforge.net/lists/listinfo/radioactive-developers |
|
From: Somen M. <som...@ra...> - 2004-10-02 21:35:12
|
Hi Felipe, When you say delete EPC, you can never really delete an epc. Perhaps you meant left the range of a reader? I agree with you, the middleware does raise events and clients can subscribe to these events (ALE). I middleware can be configured to raise any kind of events that we see fit. There is no specification, so its up to us. The middleware should keep track of all the readers connected to it. The middleware will keep track of all the events across all the readers, so if one reader detects an epc and then "deletes" it, the middleware will sense when the next reader gets the epc signal and keep track of it. I think your assuming that that relationship of reader to middleware will be one to one. There can be many readers for one middleware instance. Right now, we are dealing with one instance of the middleware, but, in the future we could have multiple instances of the middleware where we would either have to have some sort of distributed system and have all the middleware instances talk to each other OR have it done at the higher levels. We could basically have a client subscribe to each middleware instance individually. But this is something for down the road. Shaun and I had discussed a distributed style middleware based on nodes where all clients would only ever talk to a super node. This is a definite possibility. All communication for now will use JMS and http(web services).. For data, we'll always use an XML format. PML no longer exists really, but something similar. Hope that helps, Somen -----Original Message----- From: rad...@li... [mailto:rad...@li...] On Behalf Of Felipe Nascimento Sent: Friday, October 01, 2004 5:37 PM To: rad...@li... Subject: RE: [Radioactive-developers] RE: Status Hi guys, the middleware receive reads from a reader (or more than one) and can raise events, right? The most low level events I can think of are: a) added EPC; b) deleted EPC (when an epc was there and is not anymore) Will the middleware raise deletion events? If yes, will the middleware treat cases when an EPC was deleted from one reader and added to another? Or this is a higher level application responsibility? What are your thoughts about these raising events? Will different instances of middleware talk to each other, maybe to detect an EPC has moved? Or again this is a higher level app responsibility? How will events be raised, in terms of message format and protocol? PML and SOAP? JMS? This is important for me so I can visualize if I need to develop those deletion, movement, etc, functionalities in my application, or I should contribute to RadioActive, maybe in this ALE module (I believe these would be ALE's funcionalities). Tks Felipe ________________________________ From: rad...@li... [mailto:rad...@li...] On Behalf Of Somen Mondal Sent: quinta-feira, 30 de setembro de 2004 23:13 To: rad...@li...; rad...@li... Subject: [Radioactive-developers] RE: Status Hi Guys, Just wanted to give you the status of our project. We are currently developing 3 pieces of software: 1) the EPC-IS prototype 2) the middleware 3) a hardware simulator Randy is heading up the hardware simulator, and our goal is to have a driver interface to simulate different readers and to generate the reader's network traffic. Shaun, Pawel and I are developing the base EPC-IS and middleware. Once we have the base, it will be easier for more people to help develop the rest. I really think our prototype software is going to get pretty complicated and can probably be a release 0.1. Thanks, Somen ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Radioactive-developers mailing list Rad...@li... https://lists.sourceforge.net/lists/listinfo/radioactive-developers |
|
From: Somen M. <som...@ra...> - 2004-10-02 21:28:19
|
Hi Felipe, When you say delete EPC, you can never really delete an epc. Perhaps you meant left the range of a reader? I agree with you, the middleware does raise events and clients can subscribe to these events (ALE). I middleware can be configured to raise any kind of events that we see fit. There is no specification, so its up to us. The middleware should keep track of all the readers connected to it. The middleware will keep track of all the events across all the readers, so if one reader detects an epc and then "deletes" it, the middleware will sense when the next reader gets the epc signal and keep track of it. I think your assuming that that relationship of reader to middleware will be one to one. There can be many readers for one middleware instance. Right now, we are dealing with one instance of the middleware, but, in the future we could have multiple instances of the middleware where we would either have to have some sort of distributed system and have all the middleware instances talk to each other OR have it done at the higher levels. We could basically have a client subscribe to each middleware instance individually. But this is something for down the road. Shaun and I had discussed a distributed style middleware based on nodes where all clients would only ever talk to a super node. This is a definite possibility. All communication for now will use JMS and http(web services).. For data, we'll always use an XML format. PML no longer exists really, but something similar. Hope that helps, Somen -----Original Message----- From: rad...@li... [mailto:rad...@li...] On Behalf Of Felipe Nascimento Sent: Friday, October 01, 2004 5:37 PM To: rad...@li... Subject: RE: [Radioactive-developers] RE: Status Hi guys, the middleware receive reads from a reader (or more than one) and can raise events, right? The most low level events I can think of are: a) added EPC; b) deleted EPC (when an epc was there and is not anymore) Will the middleware raise deletion events? If yes, will the middleware treat cases when an EPC was deleted from one reader and added to another? Or this is a higher level application responsibility? What are your thoughts about these raising events? Will different instances of middleware talk to each other, maybe to detect an EPC has moved? Or again this is a higher level app responsibility? How will events be raised, in terms of message format and protocol? PML and SOAP? JMS? This is important for me so I can visualize if I need to develop those deletion, movement, etc, functionalities in my application, or I should contribute to RadioActive, maybe in this ALE module (I believe these would be ALE's funcionalities). Tks Felipe ________________________________ From: rad...@li... [mailto:rad...@li...] On Behalf Of Somen Mondal Sent: quinta-feira, 30 de setembro de 2004 23:13 To: rad...@li...; rad...@li... Subject: [Radioactive-developers] RE: Status Hi Guys, Just wanted to give you the status of our project. We are currently developing 3 pieces of software: 1) the EPC-IS prototype 2) the middleware 3) a hardware simulator Randy is heading up the hardware simulator, and our goal is to have a driver interface to simulate different readers and to generate the reader's network traffic. Shaun, Pawel and I are developing the base EPC-IS and middleware. Once we have the base, it will be easier for more people to help develop the rest. I really think our prototype software is going to get pretty complicated and can probably be a release 0.1. Thanks, Somen ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Radioactive-developers mailing list Rad...@li... https://lists.sourceforge.net/lists/listinfo/radioactive-developers |
|
From: Felipe N. <fel...@in...> - 2004-10-01 21:31:38
|
Hi guys, the middleware receive reads from a reader (or more than one) and can raise events, right? The most low level events I can think of are: a) added EPC; b) deleted EPC (when an epc was there and is not anymore) Will the middleware raise deletion events? If yes, will the middleware treat cases when an EPC was deleted from one reader and added to another? Or this is a higher level application responsibility? What are your thoughts about these raising events? Will different instances of middleware talk to each other, maybe to detect an EPC has moved? Or again this is a higher level app responsibility? How will events be raised, in terms of message format and protocol? PML and SOAP? JMS? This is important for me so I can visualize if I need to develop those deletion, movement, etc, functionalities in my application, or I should contribute to RadioActive, maybe in this ALE module (I believe these would be ALE's funcionalities). Tks Felipe ________________________________ From: rad...@li... [mailto:rad...@li...] On Behalf Of Somen Mondal Sent: quinta-feira, 30 de setembro de 2004 23:13 To: rad...@li...; rad...@li... Subject: [Radioactive-developers] RE: Status Hi Guys, Just wanted to give you the status of our project. We are currently developing 3 pieces of software: 1) the EPC-IS prototype 2) the middleware 3) a hardware simulator Randy is heading up the hardware simulator, and our goal is to have a driver interface to simulate different readers and to generate the reader's network traffic. Shaun, Pawel and I are developing the base EPC-IS and middleware. Once we have the base, it will be easier for more people to help develop the rest. I really think our prototype software is going to get pretty complicated and can probably be a release 0.1. Thanks, Somen |
|
From: Somen M. <som...@ra...> - 2004-10-01 16:52:34
|
Hi, Check out this link, it might help. http://www.rfidtalk.com/showthread.php?s=&threadid=376 Thanks, Somen -----Original Message----- From: rad...@li... [mailto:rad...@li...] On Behalf Of Shaun Ricci Sent: Friday, October 01, 2004 11:27 AM To: rad...@li...; kas...@al... Subject: Re: [Radioactive-developers] dev kit Hi > i am looking for a hardware developper kit. to be hands on on RFID. Any > suggestions ? The only ones I have researched are from Matrics and Alien, and they were expensive...somewhere in the $5k US range. Hope that helps. Thanks Shaun ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Radioactive-developers mailing list Rad...@li... https://lists.sourceforge.net/lists/listinfo/radioactive-developers |
|
From: Shaun R. <sha...@ra...> - 2004-10-01 15:28:42
|
Hi > i am looking for a hardware developper kit. to be hands on on RFID. Any > suggestions ? The only ones I have researched are from Matrics and Alien, and they were expensive...somewhere in the $5k US range. Hope that helps. Thanks Shaun |
|
From: kemal a. <kas...@al...> - 2004-10-01 13:24:10
|
i am looking for a hardware developper kit. to be hands on on RFID. Any suggestions ? thanks, Kemal |
|
From: Somen M. <som...@ra...> - 2004-10-01 03:52:27
|
Hi, I was wondering if anyone wanted to redesign our webpage. Just make it more user-friendly and little better looking. If anyone has these skills, email me. Thanks, Somen |
|
From: Somen M. <som...@ra...> - 2004-10-01 02:13:20
|
Hi Guys, Just wanted to give you the status of our project. We are currently developing 3 pieces of software: 1) the EPC-IS prototype 2) the middleware 3) a hardware simulator Randy is heading up the hardware simulator, and our goal is to have a driver interface to simulate different readers and to generate the reader's network traffic. Shaun, Pawel and I are developing the base EPC-IS and middleware. Once we have the base, it will be easier for more people to help develop the rest. I really think our prototype software is going to get pretty complicated and can probably be a release 0.1. Thanks, Somen |
|
From: Shaun R. <sha...@ra...> - 2004-09-23 20:03:41
|
Hey all, Now that I have been using Eclipse a bit, and comparing it with NetBeans...I like NetBeans better. They are both open source, both have refactoring, both multiplatform. The UI on NetBeans just seems more intuitive to me. Realistically , we could use either..but I think that using the "Project" feature of each one is a good way to organize things. If you have no objections, then we are going to go ahead. If you hate NetBeans, or just really really like Eclipse, then reply back. Thanks, Shaun |
|
From: Shaun R. <sha...@ra...> - 2004-09-22 17:53:49
|
Hi Felipe, > Are the ALE requisites already specified? I ask this because I would like > to simulate the ALE interface to the applications, so my app could > subscribe to this simulator. This way I could begin defining my low level > interfaces. There are no requisites specified for the ALE. Neither by us, or by EPC Global. As far as we are concerned, the middleware must have ALE that can be subscribed to. As far as the different types of events, well....that is what we are flushing out now. The prototype will be limited. In our (middleware) requirements now, it just states that there must be events available for applications to subscribe to, but we are looking to the designer of that module to really take charge and flush out more requirements and design. Any contribution you can provide coming out of your academic research would help out :-). Feel free to hop into the IRC channel if you ever have time, and you can usually find someone there to discuss more with. Visit #radioactive on the FreeNode IRC Network. Cheers, Shaun |
|
From: Felipe N. <fel...@in...> - 2004-09-22 14:15:24
|
Hi, Are the ALE requisites already specified? I ask this because I would = like to simulate the ALE interface to the applications, so my app could = subscribe to this simulator. This way I could begin defining my low level interfaces. Tks again Felipe -----Original Message----- From: Shaun Ricci [mailto:sha...@ra...]=20 Sent: ter=E7a-feira, 21 de setembro de 2004 16:02 To: rad...@li... Cc: Felipe Nascimento Subject: Re: [Radioactive-developers] Academic RFID/EPC project Hello Felipe, > New to RFID/EPC as I am, I've been reading a lot of stuff. Yesterday I = > was reading "Auto-ID Savant Specification 1.0", which talks about "The = > Reference Implementation for Savant 1.0". Is that public? Are you guys = > using this implementation as the basis for RadioActive's = implementation? The document you mention above is public, however - it is also outdated = and not so applicable to the EPC network (or standards) as they stand now. = That being said, are we using that document? We are using that document as "inspiration" for our middleware software, but there is no standard "middleware" in the EPC framework anymore. There does need to be some = sort of ALE based middleware that applications can sbuscribe to and to give = the RadioActive EPC-IS EPC data....and that is one application we are developing. I hope that helps. Your probject sounds interesting, please keep in = touch. Cheers, Shaun |
|
From: Felipe N. <fel...@in...> - 2004-09-21 19:46:51
|
Tks Shaun for the quick reply. Do you guys have an estimate of when radioactives's prototypes will = launch? How many are working on the project? I'll read radioactive's documents....maybe I can help. Felipe -----Original Message----- From: Shaun Ricci [mailto:sha...@ra...]=20 Sent: ter=E7a-feira, 21 de setembro de 2004 16:02 To: rad...@li... Cc: Felipe Nascimento Subject: Re: [Radioactive-developers] Academic RFID/EPC project Hello Felipe, > New to RFID/EPC as I am, I've been reading a lot of stuff. Yesterday I = > was reading "Auto-ID Savant Specification 1.0", which talks about "The = > Reference Implementation for Savant 1.0". Is that public? Are you guys = > using this implementation as the basis for RadioActive's = implementation? The document you mention above is public, however - it is also outdated = and not so applicable to the EPC network (or standards) as they stand now. = That being said, are we using that document? We are using that document as "inspiration" for our middleware software, but there is no standard "middleware" in the EPC framework anymore. There does need to be some = sort of ALE based middleware that applications can sbuscribe to and to give = the RadioActive EPC-IS EPC data....and that is one application we are developing. I hope that helps. Your probject sounds interesting, please keep in = touch. Cheers, Shaun |
|
From: Shaun R. <sha...@ra...> - 2004-09-21 19:03:23
|
Hello Felipe, > New to RFID/EPC as I am, I've been reading a lot of stuff. Yesterday I was > reading "Auto-ID Savant Specification 1.0", which talks about "The > Reference Implementation for Savant 1.0". Is that public? Are you guys > using this implementation as the basis for RadioActive's implementation? The document you mention above is public, however - it is also outdated and not so applicable to the EPC network (or standards) as they stand now. That being said, are we using that document? We are using that document as "inspiration" for our middleware software, but there is no standard "middleware" in the EPC framework anymore. There does need to be some sort of ALE based middleware that applications can sbuscribe to and to give the RadioActive EPC-IS EPC data....and that is one application we are developing. I hope that helps. Your probject sounds interesting, please keep in touch. Cheers, Shaun |
|
From: Felipe N. <fel...@in...> - 2004-09-21 18:45:04
|
Hi, My name is Felipe. I'm a master degree student at PUC-Rio, Brazil. My master's dissertation is to develop a application based on RFID/EPC and Multi-Agent Systems concepts. New to RFID/EPC as I am, I've been reading a lot of stuff. Yesterday I was reading "Auto-ID Savant Specification 1.0", which talks about "The Reference Implementation for Savant 1.0". Is that public? Are you guys using this implementation as the basis for RadioActive's implementation? Tks Felipe |
|
From: Shaun R. <sha...@ra...> - 2004-09-20 23:05:36
|
Hi, There are three empty modules on cvs now, giving us a total of 4 including documentation. The new ones are: common epc_is_prototype middleware_prototype Like I said, they are empty now, but we will be adding files soon, so remember to do an update on any module you will be working in. Cheers, Shaun |
|
From: Somen M. <som...@ut...> - 2004-09-19 17:33:53
|
Hi Guys, Thanks to Pawel, our development environment document as just been updated. Check it out here: http://developers.radioactivehq.org/docs.html Thanks, Somen |
|
From: Somen M. <som...@ra...> - 2004-09-14 00:22:04
|
Hi Guys, Shaun and I put up all the tasks on SF. Check them out here: https://sourceforge.net/pm/?group_id=115899 (under development). Email me with which task you guys are interested in them, and we will assign them to you in SourceForge. This way we can keep track of everyone's progress. Each task is also a heading in the design docs if you want some clarification. Hopefully, the development of this prototype will go smoothly. Thanks again! Regards, Somen |
|
From: Somen M. <som...@ra...> - 2004-09-10 02:57:34
|
Finally! The prototype design and requirements are done for both the EPC-IS and the RFID middleware. All docs are located here: http://developers.radioactivehq.org/docs.html Now, we will need to code this. When you have time, read through the document and email Shaun or I which part your most interested in coding or helping with. Hopefully, we can commence coding ASAP =) Thanks again, Somen |
226 messages has been excluded from this view by a project administrator.
