[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

RE : Need help to review the omninotify control file.



PICCA Frédéric-Emmanuel wrote:
> Section: science         

> What's sciency about it?  I thought the idea of this CORBA
> middleware stuff was to be flavourless, equally suitable for
> academic, corporate, and indeed military applications?  Most of the
> packages I find when I search on "omniorb" or "corba" are in
> "Section: devel", but for a package that's going to be installed on
> production systems that doesn't seem right either.

I already saw this but as this package will be hosted by te debian-science their policy requiered to put
Section: science.

To be honest this package is used by the tango constrol system http://tango-controls.org which is
part of the debian science acquisition task http://blends.alioth.debian.org/science/tasks/dataacquisition

It seems that is is no more maintain except that the european synchrotron http://www.esrf.fr paid to fix bug
in the package by the maintream authors.

that is why I put science :)

>> Description: multi-threaded CORBA Notification Service

>This implies that its competitors are single-threaded, which seems
>unlikely.  If the "multi-threaded" part isn't a distinctive feature
>of omninotify, it shouldn't be in the synopsis (it is after all in
>the first line of the extended description); but is there anything
>to replace it?

In fact I did not try to find a competitor of this CORBA notification Service.
except with a apt-cache search notify. I found the tao-notify system but when I
asked the tango community if they know about this they told me that they support only the omninotify
system. Their software use some specific omninotify specific configuration parameters to start
a notifd (daemon) per computer they use.

>>  omniNotify is a multi-threaded implementation of the
>>  CORBA Notification Service (CosNotification), a feature-enriched
>>  version of the CORBA Event Service (CosEvents).

>This isn't much of an explanation, given that it's defining
>omniNotify in terms most of which are still too obscure to look up
>in wikipedia - Google's first page of hits for "CosEvents" finds
>plenty of cosplayers, but no CORBA programmers!  It might help to
>include the "built on top of OmniORB" part from the homepage, since
>explanations of what OmniORB is are already available via apt-cache.

ok I understand, you are right. this is better to simplify and explain thaht it is build on top
of the CORBA system.

>  omniNotify offers asynchronous, decoupled, event-based
>  communication between distributed and heterogeneous applications.

> Now, this bit's pretty informative, though it could do without
> upstream's insistent repetition of the product name.

Ok so lets remove the Omninotify publicity :)

> >   * Scalable filter evaluation and event dispatching architecture.

> Then suddenly we're in a features list.  The first bulletpoint is an
> awkward one to start with (it features architecture?), and might
> work better if it was broken out into the main text:

Yes I do not understand exactly what is it all about.

>   omniNotify is a multi-threaded implementation of the CORBA Notification
>   Service (CosNotification), a feature-enriched version of the CORBA Event
>   Service (CosEvents) built on top of OmniORB. It offers asynchronous,
>   decoupled, event-based communication between distributed and
>   heterogeneous applications. omniNotify has a scalable filter
>   evaluation and event dispatching architecture, which supports:

Yes it is clearer like this.

>    * push-based and pull-based event suppliers and consumers;
>    * variants of suppliers/consumers that transmit (per push/pull)
>      a CosNotification::StructuredEvent (a single structured event),
>      a CosNotification::EventBatch (a sequence of structured events),
>      and a CORBA::Any (a single arbitrary value);
>    * administrative and Notification QoS properties;
>    * CosEvents backward compatibility.

ok let's do the trick like this.

> (Or was the order of sub-bullets C1/C2/C3 significant?)

I don't think so.

>  This package contains the notifd daemon.

> It's called "notifd"?  Seems a bit of a namespace hog (the first
> thing the package name made me think of was inotify, not
> omniorb), but that's definitely getting outside d-l-e jurisdiction.

that is why I decided to create an omninotify binary package instead of a
notifd one.

> I must get around to submitting my wishlist bug for "lintian -s" to
> include a check for "recycled package synopsis". 

Yes you are right cut and past all the time...

Thanks


Frederic


Reply to: