modio

10 views
Skip to first unread message

Phoenix

unread,
Dec 14, 2009, 8:14:19 AM12/14/09
to Discuss a Human Project
Lets discuss about modio here.

Владимир Савчик

unread,
Dec 14, 2009, 2:54:09 PM12/14/09
to ahuman-...@googlegroups.com
Couple of times pressed wrong buttons - don't be surprised.
Looks like my answer was sent to you only.

To avoid rewriting it again - could you please add it to the page (hope you receive it)?

2009/12/14 Phoenix <sarbjit...@gmail.com>
Lets discuss about modio here.

--
You received this message because you are subscribed to the Google
Groups "Discuss a Human Project" group.
To post to this group, send email to ahuman-...@googlegroups.com

Phoenix

unread,
Dec 14, 2009, 11:46:02 PM12/14/09
to Discuss a Human Project
modio - as it was designed before, modio module is going to be a smth
like middle-ware allowing other components to interact.
Its concept is taken from JMS servers/topics/subscriptions.
It should allow to have flexible dependencies among components while
supporting high-speed interactions.

Top-level concept items:
- is channel which can be one-direction or full duplex
- channel can be asynchronous or synchronous
- channel should store messages and allow to establish message stream
- modio doesn't know anything about components and their meaning, but
has configured set of "points of interest" - topics (and their sync/
async properties)
- flexibility is established using dynamic linking at a cost of
initial connections

Extending modio can be done in directions of supporting data exchange
concepts - shared memory, shared cache, streaming video.
Not sure what will be required, but idea is to have all the design
decisions about effective data exchange within AI engine keep inside
modio module.

On Dec 15, 12:54 am, Владимир Савчик <vsavc...@gmail.com> wrote:
> Couple of times pressed wrong buttons - don't be surprised.
> Looks like my answer was sent to you only.
>
> To avoid rewriting it again - could you please add it to the page (hope you
> receive it)?
>
> 2009/12/14 Phoenix <sarbjit.lon...@gmail.com>

Phoenix

unread,
Dec 15, 2009, 1:23:30 AM12/15/09
to Discuss a Human Project
In file Session.cpp, API void SessionImpl::setObject( Object *o ,
String name ) what is the use of ASSERT( oOld == NULL );

Do we need to make sure that it always returns null.

Владимир Савчик

unread,
Dec 15, 2009, 1:28:57 AM12/15/09
to Discuss a Human Project
I think we should check until define some contract about replaced old
objects (otherwise they will be lost)

Phoenix

unread,
Dec 15, 2009, 1:51:20 AM12/15/09
to Discuss a Human Project
I was going through the code and found following observation. It can
be wrong as I dont presently have complete view of code but still
letting you know.

I have a suggestion for class Subscriber. It can follow the command
pattern and only expose the execute function and all the classes that
derive it should give the implementation of the execute. This way we
can avoid multiple function call implementation.

The API
void SubscriptionImpl::processMessage( Message *msg ) will reduce to
mere.
sub -> execute();

The exact implementation needs to be researched.

Habbit

unread,
Dec 15, 2009, 2:31:17 AM12/15/09
to Discuss a Human Project
You are right it looks like command pattern.
But subscriber itself is not a command - it is the consumer of
messages, some of them are xml commands (e.g. debug commands) - but
other are not xml (as xml will degrade performance if used for all
communications).
Also keep in mind multiple subscriptions case.

I think we can have enhance subscription to allowing to wrap
XmlMessage as XmlCommand.
Then list of supported commands is registered via subscription and
executed by subscription w/o switch in subscriber.

Btw, we need effective cache implementation - in generic library - now
it is too slow.

Phoenix

unread,
Dec 15, 2009, 2:54:29 AM12/15/09
to Discuss a Human Project
Yes you are right. about the cache implementation i think the
algorithm to find entry is ok, it uses binary search but the algo to
add entry is heavy.

_rfc_idx_add API moves lots of data to and fro to reindex the entries
in the cache, thats tha reason its slow.

i will see if i can come up with some algo for cache implementation.

Phoenix

unread,
Dec 15, 2009, 3:58:42 AM12/15/09
to Discuss a Human Project
The API void Channel::processMessages() runs in a thread and processes
all the messages.
I think when there is no messages in queue we should put this thread
on wait, hence saving the CPU resource. When there is any message
posted in queue we should awake this thread using notify event.

Habbit

unread,
Dec 15, 2009, 5:41:16 AM12/15/09
to Discuss a Human Project
In fact we should have this as IOQueue::getNextMessage is called which
in turn goes to sleep mode until events is catched.
This is working fine currently - no waste of CPU, but if you think it
could be replaced with more simple - let me know what you mean in
terms of OS functions.

Phoenix

unread,
Dec 15, 2009, 6:51:49 AM12/15/09
to Discuss a Human Project
ohh ok i didnt traced code to that API. if its blocking than it seems
fine.
Reply all
Reply to author
Forward
0 new messages