embedlets-developer Mailing List for Outpost Embedlet Container (Page 17)
Status: Alpha
Brought to you by:
tkosan
You can subscribe to this list here.
| 2003 |
Jan
(135) |
Feb
(402) |
Mar
(162) |
Apr
(22) |
May
(13) |
Jun
(67) |
Jul
(59) |
Aug
(27) |
Sep
(1) |
Oct
(28) |
Nov
(81) |
Dec
(16) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(2) |
Feb
(21) |
Mar
(6) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
(13) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2006 |
Jan
(4) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Ted K. <tk...@ya...> - 2003-03-26 04:17:41
|
Bruce said: >In the spirit of this effort I'd be willing to create such a board >and sell it to early users at a loss. (We won't be able to recoup >our engineering costs in the first few hundred units, so if we sell >at a price of components plus out of pocket assembly, we're really >subsidizing the effort). > >So my point in sending this is to see what interest there is in us >doing so, and what the features should be. I think that having a uVM on a JSimm backplane would be a very useful device to have. For Embedlets, its looking more and more like these type of devices would be very useful for implementing JAPL peripherals and also giving these peripherals realtime capabilities. One question I have is what it would take to be able to program one of these devices through either the SPI interface or the I2C interface? It would be very nice to be able to plug a TStik into a JSIMM backplane to provide Ethernet and large memory capabilities and then to plug a few uVM JSIMM cards into the backplane in order to meet any realtime needs. It would be great if the TStik could then provision the uVM JSIMMs as needed without needing to use the serial ports. Ted __________________________________________________ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com |
|
From: Ted K. <tk...@ya...> - 2003-03-24 04:13:09
|
Andrzej,
>How are the JAPL events triggered? Interrupt? Polled?
In the case of RoboCode, the model is definitely interrupt driven. In addition
to this, the RoboCode event objects contain rich semantics that need to be
dealt with. For example, the robocode.ScannedRobotEvent contains these
methods:
double getBearing()
double getBearingRadians()
double getDistance()
double getEnergy()
double getHeading()
double getHeadingRadians()
double getLife()
String getName()
>If Interrupt driven, one way would be to write a Robot JAPL
>driver routine that implements the EventProducer interface,
>and have the Robot JAPL driver get/store a reference to the
>Event Service (there is a static method you can use in Container
>to get the EventService instance). The driver would then post
>a suitable Robot Embedlet event (using the EventService to
>send() the event) when the interrupt triggers. Downstream
>devices/components should not know what upstream components
>are "listening" for their events typically, since that produces
>too much coupling.
Before I posted my initial question I thought about this one a great deal and
what I came up with is that this would require another type of software entity
to be added to the Embedlet framework besides a Adapters, Transports and
Embedlet. Before going this route I thought that we should discuss it and
probably at least try to solve the problem another way.
Apart from this, it appears that the JAPL peripherals are well suited to use
method calls for commands being sent to them and simple callbacks for any
interrupts/events that they might generate.
>I would advise against having the JAPL device issue a callback
>against an Embedlet instance.....since that again couples the
>two layers a bit too closely. The Event Service is the preferred
>way to interface two layers together (per the above suggestions).
>Send an Event, Ted! ;-)
I am all for going with whatever makes sense here and my thinking so far on
this topic is as follows. The Architecture document already shows Embedlets
having direct references to JAPL objects and so far my RoboCode experiments
confirm that this is a good idea. If an Embedlet has a reference to a JAPL
peripheral then it is already closely coupled with it and in my opinion this is
not a problem because the JAPL's abstract nature already provides the required
level of decoupling.
The only thing we are missing now is a way for a JAPL peripheral to send
asynchronous information back to the Embedlet that has a reference to it and
using a simple callback for this purpose seems to solve this problem
adequately. If there is then a need to propagate this information to the reset
of the components in the Embedlet container then the Embedlet that contains the
JAPL peripheral can then translate the JAPL event it received into an Embedlet
event and send it to the container.
It is starting to look like there are going to eventually be thousands of JAPL
peripherals and it is going to be normal for developers to create them
'on-the-fly' just like I am doing with the RoboCode I/O systems. Since most of
a developer's effort will probably be focused on the Embedlets anyway it also
seems like it might be a good idea to have the JAPL related development be
confined to the Embedlets too.
If this line of thinking is followed to its logical conclusion then JAPL
peripherals are completely encapsulated inside of Embedlets and showing them
attached to the periphery of the Embedlet container is not an accurate
depiction.
I suppose that the 'Embedlets having direct references to JAPL peripherals'
model that is shown in the Architecture document is either a good idea or it is
not a good idea. If it is a good idea then I do not see a problem with
completing the connection by allowing the JAPL peripheral to send callbacks to
the Embedlet that contains it. If it is not a good idea then this implies that
Embedlets should not contain direct references to JAPL peripherals at all and
then we will need to come up with another way to solve this problem.
At this point I would vote for exploring the callback model and see how it
plays.
>ComponentContext objects are passive data holders ONLY! They
>should never be registered as a callback object, since that would
>imply that they would have to have application logic in them.
Well, am I correct in assuming that the container only instantiates one
conventional instance of each Embedlet and that the ComponentContext objects
are then used to hold the state of multiple Embedlets? If so, then is it
reasonable to have the one conventional Embedlet instance hold references to
JAPL peripherals (in instance variables) and also register itself for any
callbacks?
I am looking forward to hearing yours and others thoughts on this issue.
Ted
__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com
|
|
From: Andrzej J. T. <an...@ch...> - 2003-03-23 21:01:03
|
Ted: > My first thought was to use a JaplEventListener interface that Embedlets > can implement and then the Embedlet instance in question can register as > an event listener to the JAPL device it has a reference to. But of course the > state of an Embedlet is held within a ComponentContext object so how does one > register a ComponentContext object instance as a listener to JAPL events? How are the JAPL events triggered? Interrupt? Polled? If polled, then you can create a small polling embedlet that polls the JAPL device (using the Timer Service) on a regular basis, and then posts a Robot Embedlet Event when something interesting is detected. If Interrupt driven, one way would be to write a Robot JAPL driver routine that implements the EventProducer interface, and have the Robot JAPL driver get/store a reference to the Event Service (there is a static method you can use in Container to get the EventService instance). The driver would then post a suitable Robot Embedlet event (using the EventService to send() the event) when the interrupt triggers. Downstream devices/components should not know what upstream components are "listening" for their events typically, since that produces too much coupling. ComponentContext objects are passive data holders ONLY! They should never be registered as a callback object, since that would imply that they would have to have application logic in them. I would advise against having the JAPL device issue a callback against an Embedlet instance.....since that again couples the two layers a bit too closely. The Event Service is the preferred way to interface two layers together (per the above suggestions). Send an Event, Ted! ;-) Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Brill P. <bri...@ro...> - 2003-03-23 16:43:50
|
http://systronix.com/tinistamp/tinimodule.html - Brill |
|
From: Andrzej J. T. <an...@ch...> - 2003-03-23 14:54:47
|
Ted get's excited with his robot code: > The main problem I have run into so far is that RoboCode limits each robot to > only having 5 threads and this limit is hardwired into the code. The RoboCode > license expressly forbids decompiling or modifying the code so I am going to > get on the RoboCode list tomorrow and ask if I can have written permission to > up the number of robot threads for experimental purposes. Keep in mind that the current Outpost container uses 7 threads by default: main thread, dispatcher thread and 5 event propagation threads. However, these default values can be overriden using properties that the Event Manager reads on startup, so you could easily set the Event Manager to only use 3 event propagation threads. One of the beauties of Outpost for this kind of application is that the event- based model means your application code (embedlets) are isolated from the having to know about threads, and you can modularize your code base by passing events around between components. For example: Threat detection embedlet, Transport embedlet (movement), Attack embedlet, etc. I hope to have some time in the evenings this week to start work on the XML configuration parsing for Outpost, to make it even easier to set up, add components, etc. Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Ted K. <tk...@ya...> - 2003-03-23 07:34:19
|
Using RoboCode to experiment with the Embedlet codebase has turned out to be a good idea so far. I am in the process of making a JAPL RobotScanner peripheral which will be used to allow an Embedlet to monitor/control the robot scanning subsystem of the robot it is inside of. Currently the Embedlets architecture discussion document shows an Embedlet holding a reference to the JAPL peripheral it is interested in and so far this ideas is working out well. The current problem I am having, however, is how does one send JAPL events to an Embedlet? My first thought was to use a JaplEventListener interface that Embedlets can implement and then the Embedlet instance in question can register as an event listener to the JAPL device it has a reference to. But of course the state of an Embedlet is held within a ComponentContext object so how does one register a ComponentContext object instance as a listener to JAPL events? Ted __________________________________________________ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com |
|
From: Brill P. <bri...@ro...> - 2003-03-22 15:51:48
|
All sorts of info on-line. http://businessgateway.ca/en/hi/ there is a list of types, their advantages and disadvantages here: http://bsa.cbsc.org/gol/bsa/interface.nsf/engdoc/0.html - Brill Pappin ----- Original Message ----- From: "Christopher Smith" <cs...@oo...> To: <emb...@li...> Sent: Wednesday, March 19, 2003 1:25 PM Subject: RE: [Embedlets-dev] Embedlet legal entity > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > _______________________________________________ > > In the none-communistic US of A the idea of a cooperative risks a visit by > the Department of Home Land Security. (didn't the acronym SS have something > to do with security?) > > Anyway the legal entities here are: > > 1. Sole Proprietorship - no legal protection, taxable at personal rate > - N/A for us > > 2. Limited Liability Partnership > - legal protection and ownership rights > - profits/taxes flow through to partners > - no issuable stock > - relatively simple reporting requirements > - equal voting rights > > 3. Sub-chapter S corporation > - legal protection and ownership rights > - profits/taxes flow through to shareholders > - no public stock issuable > - more complicated reporting/accounting > - % of shares based voting rights > - can be converted to public corp (below) > > 4. Sub Chapter C corporation > - best legal protection and ownership rights > - profits/taxes retained in corp until distributed > - issuable public stock > - complicated reporting once public > - % of shares based voting > > #2 LLP is new in most states and is quickly catching on as the preferred > professional partnership arrangement. > > Does anyone have info on a Canadian cooperative? All I know is that we used > to take milk from my dad's farm to the CO-OP in Guelph and looked forward to > those big dividend checks (~$25.00) every quarter :). > > > > > > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > > _______________________________________________ > > > > Its a little more complicated because of the nature of the beast I think. > > > > I'm not really knowledgeable on this sort of thing, but what > > about a co-op? > > I know we can do that in Canada, but I don't know about the > > states, or what > > the benefits would be as a business entity. > > > > - Brill Pappin > > > > ----- Original Message ----- > > From: "Ted Kosan" <tk...@ya...> > > To: <emb...@li...> > > Sent: Tuesday, March 18, 2003 2:46 AM > > Subject: [Embedlets-dev] Embedlet legal entity > > > > > > > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > > > _______________________________________________ > > > > > > Before I started researching what it is going to take to create an > > Embedlet > > > legal entity to reference in the Embedlet license, does anyone have any > > > thoughts on this? > > > > > > Ted > > > > > > __________________________________________________ > > > Do you Yahoo!? > > > Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! > > > http://platinum.yahoo.com > > > > > > > > > ------------------------------------------------------- > > > This SF.net email is sponsored by:Crypto Challenge is now open! > > > Get cracking and register here for some mind boggling fun and > > > the chance of winning an Apple iPod: > > > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en > > > _______________________________________________ > > > Embedlets-developer mailing list > > > Emb...@li... > > > https://lists.sourceforge.net/lists/listinfo/embedlets-developer > > > > > > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: Does your code think in ink? > > You could win a Tablet PC. Get a free Tablet PC hat just for playing. > > What are you waiting for? > > http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en > > _______________________________________________ > > Embedlets-developer mailing list > > Emb...@li... > > https://lists.sourceforge.net/lists/listinfo/embedlets-developer > > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Does your code think in ink? > You could win a Tablet PC. Get a free Tablet PC hat just for playing. > What are you waiting for? > http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en > _______________________________________________ > Embedlets-developer mailing list > Emb...@li... > https://lists.sourceforge.net/lists/listinfo/embedlets-developer > |
|
From: Ted K. <tk...@ya...> - 2003-03-22 08:41:09
|
Early today I decided that I finally had enough of a handle on the code base to start thinking about developing some embedlets of my own. After thinking a while about what type of application I would like to start with I finally decided to try to get Outpost to run inside of a RoboCode robot. And guess what, it works! I have not had a chance yet to develop any robot specific embedlets but my little EmbedletBot test robot shot the snot out of the SittingDuck robot while the logging service read out the embedlet event traffic on the EmbedletBot's terminal screen. I can't wait to see if I can interface some of the robot's sensors to the Outpost container using JAPL peripherals and then write some embedlet based robot logic! The main problem I have run into so far is that RoboCode limits each robot to only having 5 threads and this limit is hardwired into the code. The RoboCode license expressly forbids decompiling or modifying the code so I am going to get on the RoboCode list tomorrow and ask if I can have written permission to up the number of robot threads for experimental purposes. Ted __________________________________________________ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com |
|
From: Nicola K. B. <nic...@ap...> - 2003-03-21 23:07:12
|
Ted Kosan wrote, On 21/03/2003 23.46: > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > _______________________________________________ > > Chris, > >>Anyway the legal entities here are: [snip] > > Do non-profit organizations fall under one of these 4 categories? I wonder > what foundations like Apache are set up as? A Delaware corporation, organized not for profit, pursuant to the provisions of Section 108 of the Delaware General Corporation Law. http://www.apache.org/foundation/records/certificate.html http://www.apache.org/foundation/records/incorporator.html http://www.apache.org/foundation/bylaws.html -- Nicola Ken Barozzi nic...@ap... - verba volant, scripta manent - (discussions get forgotten, just code remains) --------------------------------------------------------------------- |
|
From: Ted K. <tk...@ya...> - 2003-03-21 22:46:44
|
Chris, > Anyway the legal entities here are: [snip] Do non-profit organizations fall under one of these 4 categories? I wonder what foundations like Apache are set up as? Ted --- Christopher Smith <cs...@oo...> wrote: > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > _______________________________________________ > > In the none-communistic US of A the idea of a cooperative risks a visit by > the Department of Home Land Security. (didn't the acronym SS have something > to do with security?) > > Anyway the legal entities here are: > > 1. Sole Proprietorship - no legal protection, taxable at personal rate > - N/A for us > > 2. Limited Liability Partnership > - legal protection and ownership rights > - profits/taxes flow through to partners > - no issuable stock > - relatively simple reporting requirements > - equal voting rights > > 3. Sub-chapter S corporation > - legal protection and ownership rights > - profits/taxes flow through to shareholders > - no public stock issuable > - more complicated reporting/accounting > - % of shares based voting rights > - can be converted to public corp (below) > > 4. Sub Chapter C corporation > - best legal protection and ownership rights > - profits/taxes retained in corp until distributed > - issuable public stock > - complicated reporting once public > - % of shares based voting > > #2 LLP is new in most states and is quickly catching on as the preferred > professional partnership arrangement. > > Does anyone have info on a Canadian cooperative? All I know is that we used > to take milk from my dad's farm to the CO-OP in Guelph and looked forward to > those big dividend checks (~$25.00) every quarter :). > > > > > > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > > _______________________________________________ > > > > Its a little more complicated because of the nature of the beast I think. > > > > I'm not really knowledgeable on this sort of thing, but what > > about a co-op? > > I know we can do that in Canada, but I don't know about the > > states, or what > > the benefits would be as a business entity. > > > > - Brill Pappin > > > > ----- Original Message ----- > > From: "Ted Kosan" <tk...@ya...> > > To: <emb...@li...> > > Sent: Tuesday, March 18, 2003 2:46 AM > > Subject: [Embedlets-dev] Embedlet legal entity > > > > > > > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > > > _______________________________________________ > > > > > > Before I started researching what it is going to take to create an > > Embedlet > > > legal entity to reference in the Embedlet license, does anyone have any > > > thoughts on this? > > > > > > Ted > > > > > > __________________________________________________ > > > Do you Yahoo!? > > > Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! > > > http://platinum.yahoo.com > > > > > > > > > ------------------------------------------------------- > > > This SF.net email is sponsored by:Crypto Challenge is now open! > > > Get cracking and register here for some mind boggling fun and > > > the chance of winning an Apple iPod: > > > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en > > > _______________________________________________ > > > Embedlets-developer mailing list > > > Emb...@li... > > > https://lists.sourceforge.net/lists/listinfo/embedlets-developer > > > > > > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: Does your code think in ink? > > You could win a Tablet PC. Get a free Tablet PC hat just for playing. > > What are you waiting for? > > http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en > > _______________________________________________ > > Embedlets-developer mailing list > > Emb...@li... > > https://lists.sourceforge.net/lists/listinfo/embedlets-developer > > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Does your code think in ink? > You could win a Tablet PC. Get a free Tablet PC hat just for playing. > What are you waiting for? > http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en > _______________________________________________ > Embedlets-developer mailing list > Emb...@li... > https://lists.sourceforge.net/lists/listinfo/embedlets-developer __________________________________________________ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com |
|
From: Andrzej J. T. <an...@ch...> - 2003-03-20 00:30:53
|
Gregg clarified: > Using a topic based event system allow subscribers and publishers to be > unknowing of each others presence. As events are published, there can be > zero or more subscribers, including subscribers whose job is to distribute > events into external systems. The topic is important because it lets you > authorize access to parts of the system separate from the data that is flowing. > In our 'Edge Broker', we use a topic system that puts data items flowing into > the system into a tree such as > > app.data.gh.0 > app.data.gh.2 > app.data.gh.3 > app.data.rm.0 > app.data.rm.6 > app.data.rm.2 > app.data.rm.3 It's worth noting that the current Outpost implementation uses this kind of "topic" (or event type) system as well. When registering for specific event types you can use the * designator to match any single token (between dots) or ** to match any number of tokens. Details in the Event javadocs. ...Andrzej Chaeron Corporation http://www.chaeron.com |
|
From: Christopher S. <cs...@oo...> - 2003-03-19 18:25:29
|
In the none-communistic US of A the idea of a cooperative risks a visit by the Department of Home Land Security. (didn't the acronym SS have something to do with security?) Anyway the legal entities here are: 1. Sole Proprietorship - no legal protection, taxable at personal rate - N/A for us 2. Limited Liability Partnership - legal protection and ownership rights - profits/taxes flow through to partners - no issuable stock - relatively simple reporting requirements - equal voting rights 3. Sub-chapter S corporation - legal protection and ownership rights - profits/taxes flow through to shareholders - no public stock issuable - more complicated reporting/accounting - % of shares based voting rights - can be converted to public corp (below) 4. Sub Chapter C corporation - best legal protection and ownership rights - profits/taxes retained in corp until distributed - issuable public stock - complicated reporting once public - % of shares based voting #2 LLP is new in most states and is quickly catching on as the preferred professional partnership arrangement. Does anyone have info on a Canadian cooperative? All I know is that we used to take milk from my dad's farm to the CO-OP in Guelph and looked forward to those big dividend checks (~$25.00) every quarter :). > > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > _______________________________________________ > > Its a little more complicated because of the nature of the beast I think. > > I'm not really knowledgeable on this sort of thing, but what > about a co-op? > I know we can do that in Canada, but I don't know about the > states, or what > the benefits would be as a business entity. > > - Brill Pappin > > ----- Original Message ----- > From: "Ted Kosan" <tk...@ya...> > To: <emb...@li...> > Sent: Tuesday, March 18, 2003 2:46 AM > Subject: [Embedlets-dev] Embedlet legal entity > > > > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > > _______________________________________________ > > > > Before I started researching what it is going to take to create an > Embedlet > > legal entity to reference in the Embedlet license, does anyone have any > > thoughts on this? > > > > Ted > > > > __________________________________________________ > > Do you Yahoo!? > > Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! > > http://platinum.yahoo.com > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by:Crypto Challenge is now open! > > Get cracking and register here for some mind boggling fun and > > the chance of winning an Apple iPod: > > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en > > _______________________________________________ > > Embedlets-developer mailing list > > Emb...@li... > > https://lists.sourceforge.net/lists/listinfo/embedlets-developer > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Does your code think in ink? > You could win a Tablet PC. Get a free Tablet PC hat just for playing. > What are you waiting for? > http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en > _______________________________________________ > Embedlets-developer mailing list > Emb...@li... > https://lists.sourceforge.net/lists/listinfo/embedlets-developer > |
|
From: Brill P. <bri...@ro...> - 2003-03-19 12:20:02
|
Its a little more complicated because of the nature of the beast I think. I'm not really knowledgeable on this sort of thing, but what about a co-op? I know we can do that in Canada, but I don't know about the states, or what the benefits would be as a business entity. - Brill Pappin ----- Original Message ----- From: "Ted Kosan" <tk...@ya...> To: <emb...@li...> Sent: Tuesday, March 18, 2003 2:46 AM Subject: [Embedlets-dev] Embedlet legal entity > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > _______________________________________________ > > Before I started researching what it is going to take to create an Embedlet > legal entity to reference in the Embedlet license, does anyone have any > thoughts on this? > > Ted > > __________________________________________________ > Do you Yahoo!? > Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! > http://platinum.yahoo.com > > > ------------------------------------------------------- > This SF.net email is sponsored by:Crypto Challenge is now open! > Get cracking and register here for some mind boggling fun and > the chance of winning an Apple iPod: > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en > _______________________________________________ > Embedlets-developer mailing list > Emb...@li... > https://lists.sourceforge.net/lists/listinfo/embedlets-developer > |
|
From: Christopher S. <cs...@oo...> - 2003-03-18 16:51:55
|
The cheapest and simplest is an LLP from the state of Delaware: http://www.incnow.com/delaware-llc.htm http://www.delawarecorp.com/ http://www.corporate.com/costs.cfm https://secure.delcorp.com/llcprice.htm http://llccal.com/html/hamleg_inc_vs_llc.html > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > _______________________________________________ > > Before I started researching what it is going to take to create > an Embedlet > legal entity to reference in the Embedlet license, does anyone have any > thoughts on this? > > Ted > > __________________________________________________ > Do you Yahoo!? > Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! > http://platinum.yahoo.com > > > ------------------------------------------------------- > This SF.net email is sponsored by:Crypto Challenge is now open! > Get cracking and register here for some mind boggling fun and > the chance of winning an Apple iPod: > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en > _______________________________________________ > Embedlets-developer mailing list > Emb...@li... > https://lists.sourceforge.net/lists/listinfo/embedlets-developer > |
|
From: Gregg G. W. <gr...@sk...> - 2003-03-18 16:38:10
|
>Anyway, when either Gregg or Chris gets a chance could one of you please
>explain a little more about the philosophy behind event topics again? Also, a
>short description of one or two in-use systems that use a scheme like would be
>very helpful.
Using a topic based event system allow subscribers and publishers to be
unknowing of each others presence. As events are published, there can be
zero or more subscribers, including subscribers whose job is to distribute
events into external systems. The topic is important because it lets you
authorize access to parts of the system separate from the data that is flowing.
In our 'Edge Broker', we use a topic system that puts data items flowing into
the system into a tree such as
app.data.gh.0
app.data.gh.2
app.data.gh.3
app.data.rm.0
app.data.rm.6
app.data.rm.2
app.data.rm.3
Our pub/sub system uses user level authentication to control publishing of
topical events so that only the correct modules in the system can inject the
appropriate data. You can find the Broker via Jini, and get an RMI interface
for publishing from remote code. When you get the remote interface stub, you
have to provide your credentials. The credentials stay in the server and
confine the user to the authorized limits.
The data queue manager and the data delivery manager use topic based events to
tell each other what to do.
app.recover.<deliveryManager>.<key>
app.<QueueManager>.<key>.store.enq
app.<QueueManager>.<key>.delete.enq
app.<QueueManager>.<key>.defer.enq
app.<QueueManager>.<key>.ignore.enq
app.<DeliveryManager>.<key>.store.ack
app.<DeliveryManager>.<key>.store.nak
etc...
It is thus easy to watch what is happening with data as it flows, you can add
secondary subscribers to count or track events, perform secondary processing
etc.
<ramblings>
In a future version of the code, I can trivially distribute the system across
multiple JVMs by just using event forwarding to remote systems. I have a
design drawn up that uses Javaspaces to do this and use Jini to locate the
appropriate pieces of the system. Currently though, we are handling our
largest site at ~1500 devices on midrange machines, so I am not needing to
distribute for CPU load yet. We get 1500 hourly reports plus another 1000
alarms and/or audits per hour and then 750 of the devices publish additional
reports every 2-5 minutes. This seems like a pretty reasonable performance
with string based topics and we have done much tuning over time by using ^\
under linux to get thread dumps under load and look for places that code is
camped out on the heap monitor. In a loaded event based system of course,
queuing theory is ever present and you quickly rediscover that the system is
only as fast as the slowest event in the system. I/O based slowness can be
mitigated with threading to some degree. But, as soon as a monitor must be
touched by every thread, you have to make sure that monitor is fast...
<jiniDigression>
The Jini ServiceDiscoveryManager (SDM) tracks and caches the existance of
objects and thus allows you to just ask it for an instance of an object
matching a ServiceTemplate, and when that call returns, you have such an
object. You can put timeouts on the 'lookups' and manage them with other
steps taken when timeouts occur, if needed (very complex recoveries involving
hardware switching).
The SDM does all the hard part. If you distribute the workers across multiple
JVMs, then you can just do
// Don't need any special DiscoveryManagement or LeaseRenewalManager
ServiceDiscoveryManager sdm = new ServiceDiscoveryManager( null, null );
ServiceTemplate myTemplate = getTemplateToUse();
LookupCache lc = sdm.createLookupCache( myTemplate, null, null );
while( workToDo ) {
WorkItem wi = getNextWorkItem();
ServiceItem si = lc.lookup( null );
WorkHandler wh = (WorkHandler)si.service;
wh.handleWorkItem( wi );
}
This is the simple model... Some exception handling is needed in there, and
some retries associated with partial failure handling.
</jiniDigression>
</ramblings>
-----
gr...@cy... (Cyte Technologies Inc)
|
|
From: Ted K. <tk...@ya...> - 2003-03-18 07:46:54
|
Before I started researching what it is going to take to create an Embedlet legal entity to reference in the Embedlet license, does anyone have any thoughts on this? Ted __________________________________________________ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com |
|
From: Ted K. <tk...@ya...> - 2003-03-18 07:42:39
|
Sometime within the next week or so I would like to put together a 'Who we are' page on the Embedlets website that is similar in spirit to the following: http://avalon.apache.org/whoweare/index.html In the Ant book I have been reading it states that most open source projects do not put the code author's names into the source code itself because this encourages users to email these people whenever they have even small problems with the application. The fix here seems to be to list all code committers somewhere on the project's main web site and this sounded like a good idea to me. Anyway, as soon as everyone's bio is posted to the list I will use them to create a 'Who we are' page for the website. Ted __________________________________________________ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com |
|
From: Ted K. <tk...@ya...> - 2003-03-18 07:31:33
|
I remember that sometime within the past couple of months either Gregg or Chris posted an email that talked about an event topic scheme that they had evolved over the years. I went to search through the email archives to find this post but I could not find any search capabilities (am I missing something here?). Anyway, when either Gregg or Chris gets a chance could one of you please explain a little more about the philosophy behind event topics again? Also, a short description of one or two in-use systems that use a scheme like would be very helpful. Thanks! Ted __________________________________________________ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com |
|
From: Andrzej J. T. <an...@ch...> - 2003-03-16 20:49:59
|
> t would be helpful if everyone explicitly specified their imports rather > than use the ".*" global import... it makes it much harder to find out where > something came from when tracing/reading the code... Soon as the next release of the Jalopy source formatter comes out (and assuming it will be up to the task of enforcing our coding conventions, which based on my discussions with the author, it should), I'll put that in the build script and have Jalopy expand out the imports. If I get time, I may do this manually ahead of time. Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Andrzej J. T. <an...@ch...> - 2003-03-16 20:49:55
|
Brill: > Is the timer service you have set up emulating a hardware timer, or is it a > service in general? (I think a "service in general" would be useful). It is a general service and is not intended to emulate or otherwise replace hardware-based timers. Due to the design of the service, and the facilities provided by the underlying Java implementations, the Timer service can only provide an "approximation" of the timer duration that a component (eg. Embedlet) developer may request. So a 100 ms. repetitive timer may fire at 150 ms, 120 ms, 100ms etc. The timer service should be used for situations where the absolute timer interval is not overly critical. Hardware (and interrupt based timers) are typically used when the timing requrirements are more stringent. For example, the timer service might be more than sufficient for an Embedlet to poll the value of a sensor on a periodic basis, but would not be a good choice for the generation of a pulse stream that had a very regular high- speed frequency. Does that help? Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Ted K. <tk...@ya...> - 2003-03-16 08:21:06
|
Brill stated: > It would be helpful if everyone explicitly specified their imports rather > than use the ".*" global import... it makes it much harder to find out where > something came from when tracing/reading the code... I would second this if it is feasible. Ted __________________________________________________ Do you Yahoo!? Yahoo! Web Hosting - establish your business online http://webhosting.yahoo.com |
|
From: Brill P. <bri...@ro...> - 2003-03-16 04:59:08
|
Just a "convention" request. It would be helpful if everyone explicitly specified their imports rather than use the ".*" global import... it makes it much harder to find out where something came from when tracing/reading the code... the code-base is still fairly small, so it's not impossible to find things, however it will soon become a major pain. - Brill Pappin |
|
From: Brill P. <bri...@ro...> - 2003-03-16 04:47:55
|
I've begun going through the Embedlet/Outpost/Outhouse source and have a question (and more to come). Is the timer service you have set up emulating a hardware timer, or is it a service in general? (I think a "service in general" would be useful). - Brill Pappin |
|
From: Andrzej J. T. <an...@ch...> - 2003-03-15 22:07:07
|
> The description for the org.embedlet.Adapter class currently reads as follows: > > 'The Adapter class is the base class for all Embedlets' > I think that 'Embedlets' here should be 'Adapters'. The newer source file in CVS has been corrected already (I posted about that a week ago). > Also, could a more > detailed description of what an Adapter is be added here? Be my guest! ;-) Once we figure out what an Adapter looks like, the docs will be updated. Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Ted K. <tk...@ya...> - 2003-03-15 07:21:06
|
Andrzej, The description for the org.embedlet.Adapter class currently reads as follows: 'The Adapter class is the base class for all Embedlets' I think that 'Embedlets' here should be 'Adapters'. Also, could a more detailed description of what an Adapter is be added here? Thanks! Ted __________________________________________________ Do you Yahoo!? Yahoo! Web Hosting - establish your business online http://webhosting.yahoo.com |