I think having a common repo for the mobile agent with the rest would not be
feasible considering the language difference.
But at least, the aggregator and the desktop agent can have a common repo,
no?
On Wed, May 25, 2011 at 4:38 AM, Adriano Monteiro Marques <
[email protected]> wrote:
> Hi Zubair,
>
> On May 21, 2011, at 4:18 PM, Zubair Nabi wrote:
>
> Hello Everyone,
>
> During my meeting with Luis today, we discussed a common repository. There
> would be a number of components common between the aggregator, and agents.
> For example, the Google Protobuf .proto should be applicable across all
> entities. Other examples include the restlet resources, regex, parsers etc.
>
>
> I'm pretty sure we can share regex with the aggregator and desktop agent,
> but not sure about the mobile agent. Do you think that python regex is
> compatible with java?
> On the parsers part, what parsers do you refer to?
>
> For the protobuf messages and resources I think it is just fine to have a
> common repo to hold those.
>
> But having said this, there's a major hiccup here. The mobile agent will
> obviously be in Java while the aggregator and desktop agent would primarily
> consist of Python code. For instance, for the mobile agent this is the
> .proto (considering Java):
>
> http://dev.umitproject.org/projects/icm-mobile/repository/revisions/master/entry/ICM-Mobile/src/org/umit/icm/mobile/proto/Messages.proto
>
>
> <http://dev.umitproject.org/projects/icm-mobile/repository/revisions/master/entry/ICM-Mobile/src/org/umit/icm/mobile/proto/Messages.proto>As
> you can see, these two lines make the .proto Java-specific:
>
> 22<http://dev.umitproject.org/projects/icm-mobile/repository/revisions/master/entry/ICM-Mobile/src/org/umit/icm/mobile/proto/Messages.proto#L22>
>
> package org.umit.icm.mobile.proto.generated;
>
> 23<http://dev.umitproject.org/projects/icm-mobile/repository/revisions/master/entry/ICM-Mobile/src/org/umit/icm/mobile/proto/Messages.proto#L23>
>
> option java_outer_classname = "MessageProtos";
>
>
>
> I think the package thing will be ignored when parsed for python, have you
> you test this?
>
> Otherwise the message format is applicable to Python as well.
> Any thoughts on this?
>
>
> We could create some make files our build scripts to adapt that part of the
> code and generate proper output. That's fairly simple.
>
> --
> Best,
> __
> Zubair
> ------------------------------------------------------------------------------
> What Every C/C++ and Fortran developer Should Know!
> Read this article and learn how Intel has extended the reach of its
> next-generation tools to help Windows* and Linux* C/C++ and Fortran
> developers boost performance applications - including clusters.
>
> http://p.sf.net/sfu/intel-dev2devmay_______________________________________________
> Umit-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/umit-devel
>
>
> ---
> Adriano Monteiro Marques
>
> http://www.thoughtspad.com
> http://www.umitproject.org
> http://blog.umitproject.org
> http://www.pythonbenelux.org
>
> "Don't stay in bed, unless you can make money in bed." - George Burns
>
>
--
Best,
__
Zubair
------------------------------------------------------------------------------
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery,
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now.
http://p.sf.net/sfu/quest-d2dcopy1
_______________________________________________
Umit-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/umit-devel
