Nabble - Atalaya-dev

Re: Flash charts

2009-07-26T00:31:33Z

Is anyone using AnyCharts flash charting?

Thanks
r123

Francesco Vivoli wrote:

nice!

On Mon, Sep 8, 2008 at 12:34 AM, Roman Kalyakin <theorm@gmail.com> wrote:

> Hi there,
>
> Work is going on and there are the first results for those who want to
> improve motivation. :)
> See attached screenshot.
>
> Cheers,
> Roman
>
> On Mon, Sep 1, 2008 at 5:05 PM, <giacomo.collini@gmail.com> wrote:
>
>> I took a look to commercial alternatives like FusionChart.
>> They are quite cheap indeed but on the other hand I would like to
>> stick to the "preference to open source components and libraries"
>> policy. So I strongly support Open Flash Charts.
>>
>> Thanks,
>>
>> On Mon, Sep 1, 2008 at 11:31 AM, Francesco Vivoli <f.vivoli@gmail.com>
>> wrote:
>> > For me they look ok. If there is some other compelling reason for yahoo
>> I'll
>> > be fine with yahoo as well.
>> > ciao
>> > F
>> >
>> > On Mon, Sep 1, 2008 at 11:19 AM, Roman Kalyakin <theorm@gmail.com>
>> wrote:
>> >>
>> >> Okay. The last thing is to decide what charts to use. I suggest if
>> >> everyone is satisfied with the look'n'feel of the open flash charts,
>> let's
>> >> go for it.
>> >>
>> >> -R
>> >>
>> >> On Mon, Sep 1, 2008 at 11:16 AM, Francesco Vivoli <f.vivoli@gmail.com>
>> >> wrote:
>> >>>
>> >>> Yes, this makes sense. After all much of the work is on the data
>> format,
>> >>> which can be reused.
>> >>> F
>> >>>
>> >>> On Mon, Sep 1, 2008 at 11:14 AM, Roman Kalyakin <theorm@gmail.com>
>> wrote:
>> >>>>
>> >>>> Taking into account the limitations of the bar charts, if we want to
>> >>>> finish the charts at once without rewriting things later, that would
>> make
>> >>>> sense to implement a polar chart from the beginning. From the other
>> side, we
>> >>>> could just drop in a swf bar chart instead of the polar chart and see
>> how it
>> >>>> looks. If we don't like it - we write a polar chart extension.
>> >>>>
>> >>>> -R
>> >>>>
>> >>>>
>> >>>> On Mon, Sep 1, 2008 at 10:05 AM, Francesco Vivoli <
>> f.vivoli@gmail.com>
>> >>>> wrote:
>> >>>>>
>> >>>>> Wrt to the polar chart, don't you think that changing it for a
>> stacked
>> >>>>> bar chart is an option.
>> >>>>> We use it because we want to display multiple datasets, where each
>> >>>>> point represent a certain quantity.
>> >>>>> In the specific we are drawing a polar line (i.e, a segmented line
>> that
>> >>>>> rounds the origin:)) for each asset group (sites or bu's).
>> >>>>> Every edge represent how much that group scored for a certain
>> >>>>> appliance, right?
>> >>>>>
>> >>>>> The problem with stacked bar charts is that each data point (an
>> >>>>> appliance for a group) is bound within [0,10], so if there are 5
>> appliances
>> >>>>> the whole bar can assume values within [0,50], with the upper value
>> >>>>> increasing with the number of appliances. This could lead to some
>> >>>>> visualization problems now that I think about it. If these SDKs
>> provide
>> >>>>> zooming, which I don't know, it would be ok though.
>> >>>>>
>> >>>>> Another possibility is to have segmented bar charts (one bar per
>> >>>>> appliance/group, grouped by group), in this case we'd have lesser
>> >>>>> variability on the y's but a much wider chart.
>> >>>>>
>> >>>>> Finally, creating a polar chart in SWF would be cool. The only issue
>> >>>>> would be that I'd like for it to be better than JFreeChart's one,
>> since
>> >>>>> right now we can't even put a label for the edges (the degrees
>> numbers are
>> >>>>> hard-coded into JFree code-_-)
>> >>>>>
>> >>>>> F
>> >>>>>
>> >>>>> On Mon, Sep 1, 2008 at 9:52 AM, Roman Kalyakin <theorm@gmail.com>
>> >>>>> wrote:
>> >>>>>>
>> >>>>>> Hi Francesco,
>> >>>>>>
>> >>>>>> Yes. Open Flash Chart improved a lot within the last year. I
>> checked
>> >>>>>> both OFC and Yahoo charts and they both don't have a polar chart.
>> That means
>> >>>>>> that we have two ways: either display this data on another type of
>> chart or
>> >>>>>> implement the polar chart on top of Open Flash Chart or Yahoo
>> charts. It
>> >>>>>> requires however some knowledge of actionscript. I took a look at
>> it though,
>> >>>>>> and it doesn't look so much different comparing to Java. So, I
>> beleive it
>> >>>>>> would be not a big deal to implement it.
>> >>>>>>
>> >>>>>> Regarding the data format: Yes, JSON is more compact. And to adopt
>> >>>>>> Atalaya data format to the charts we can either change the format
>> within the
>> >>>>>> chart or implement the xml->json converter. I think the second
>> option is
>> >>>>>> better. We could even start using data in JSON format for the UI
>> too as it
>> >>>>>> is more compact.
>> >>>>>>
>> >>>>>> What to choose. For me both are ok. Yahoo SDK seems more robust and
>> >>>>>> flexible. But it requires some coding. The fact that it's Yahoo
>> also annoys
>> >>>>>> me a bit. But since it's just an SDK with primitives and not a set
>> of charts
>> >>>>>> with yahoo logo on them, it's still a candidate.
>> >>>>>>
>> >>>>>> Cheers,
>> >>>>>> -Roman
>> >>>>>>
>> >>>>>> On Mon, Sep 1, 2008 at 9:32 AM, Francesco Vivoli <
>> f.vivoli@gmail.com>
>> >>>>>> wrote:
>> >>>>>>>
>> >>>>>>> Hi Roman
>> >>>>>>>
>> >>>>>>> I had given a look at the open flash chart thang a while ago, it
>> >>>>>>> looked good then and it seems they have improved. As for the yahoo
>> sdk, I
>> >>>>>>> don't know enough about it to make a comment.The only thing is
>> that an year
>> >>>>>>> ago we decided not to use yahoo UI nor GWT, because well, there
>> was a direct
>> >>>>>>> link to these bigbig corps... I don't know, maybe it's me who's
>> too
>> >>>>>>> skeptical.
>> >>>>>>>
>> >>>>>>> Ok, speaking from a purely technical perspective I'd say let's
>> look
>> >>>>>>> at the requirements. Right now we use time series, pie and polar
>> charts.
>> >>>>>>> While the first two are supported for sure, I'm not sure about the
>> latter.
>> >>>>>>>
>> >>>>>>> In the case we can't make polar charts well, we still can rethink
>> how
>> >>>>>>> to depict the same information: a stacked bar chart could maybe do
>> the job,
>> >>>>>>> couldn't it?
>> >>>>>>>
>> >>>>>>> Then there is data format issue. As you know, right now we produce
>> >>>>>>> XML by default which could be fed into OFC, at least before.
>> Nevertheless I
>> >>>>>>> don't think it's desiderable, JSON is much more compact as a
>> format. Beside
>> >>>>>>> that, the XML that produce is atalaya-domain specific, whereas we
>> should
>> >>>>>>> produce an OFC-specific one. Wrt we should start investigating how
>> to
>> >>>>>>> produce JSON strings from our model, i.e how to refactor the all
>> >>>>>>> ChartBuilder chain.
>> >>>>>>> What do yo guys say?
>> >>>>>>>
>> >>>>>>> ciao
>> >>>>>>> F
>> >>>>>>>
>> >>>>>>> On Fri, Aug 29, 2008 at 7:32 PM, Roman Kalyakin <theorm@gmail.com
>> >
>> >>>>>>> wrote:
>> >>>>>>>>
>> >>>>>>>> Hi,
>> >>>>>>>>
>> >>>>>>>> As we discussed one of our initial goals is to move towards nice
>> >>>>>>>> charts, possibly flash. I've been checking current situation with
>> flash
>> >>>>>>>> charts in opensource world and found this project:
>> >>>>>>>> http://teethgrinder.co.uk/open-flash-chart-2
>> >>>>>>>> I saw it before, but it used to be a charting server running on
>> php.
>> >>>>>>>> Now, in version 2 they moved towards pure SWF + JSON. The charts
>> look nice
>> >>>>>>>> and easy to use. It's GPL v2.
>> >>>>>>>>
>> >>>>>>>> There is another project that is worth attention:
>> >>>>>>>>
>> http://developer.yahoo.com/flash/astra-flash/charts/examples.html.
>> >>>>>>>> It's a Yahoo SDK for flash and is not for charts only. The SDK is
>> >>>>>>>> under BSD. The only problem is that it's not a ready made SWF
>> that reads
>> >>>>>>>> data from external file, thus it needs some flash/actionscript
>> development
>> >>>>>>>> skills. However this option is more flexible because the SDK
>> seems to
>> >>>>>>>> include a huge variety of primitives.
>> >>>>>>>>
>> >>>>>>>> What do you guys think?
>> >>>>>>>>
>> >>>>>>>> Cheers,
>> >>>>>>>> -Roman
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> -------------------------------------------------------------------------
>> >>>>>>>> This SF.Net email is sponsored by the Moblin Your Move
>> Developer's
>> >>>>>>>> challenge
>> >>>>>>>> Build the coolest Linux based applications with Moblin SDK & win
>> >>>>>>>> great prizes
>> >>>>>>>> Grand prize is a trip for two to an Open Source event anywhere in
>> >>>>>>>> the world
>> >>>>>>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> >>>>>>>> _______________________________________________
>> >>>>>>>> Atalaya-developer mailing list
>> >>>>>>>> Atalaya-developer@lists.sourceforge.net
>> >>>>>>>> https://lists.sourceforge.net/lists/listinfo/atalaya-developer
>> >>>>>>>>
>> >>>>>>>
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>
>> >
>> >
>> >
>> -------------------------------------------------------------------------
>> > This SF.Net email is sponsored by the Moblin Your Move Developer's
>> challenge
>> > Build the coolest Linux based applications with Moblin SDK & win great
>> > prizes
>> > Grand prize is a trip for two to an Open Source event anywhere in the
>> world
>> > http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> > _______________________________________________
>> > Atalaya-developer mailing list
>> > Atalaya-developer@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/atalaya-developer
>> >
>> >
>>
>>
>>
>> --
>> Giacomo Collini - CISSP
>>
>> Information Security Analyst
>>
>>
>> email: giacomo.collini@gmail.com
>> mobile: (+34)628332736
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win great
>> prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the
>> world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> Atalaya-developer mailing list
>> Atalaya-developer@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/atalaya-developer
>>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Atalaya-developer mailing list
> Atalaya-developer@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/atalaya-developer
>
>

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Atalaya-developer mailing list
Atalaya-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/atalaya-developer

Re: Flash charts

2009-07-26T00:31:31Z

Is anyone using AnyCharts flash charting?

Thanks
r123

Francesco Vivoli wrote:

nice!

On Mon, Sep 8, 2008 at 12:34 AM, Roman Kalyakin <theorm@gmail.com> wrote:

> Hi there,
>
> Work is going on and there are the first results for those who want to
> improve motivation. :)
> See attached screenshot.
>
> Cheers,
> Roman
>
> On Mon, Sep 1, 2008 at 5:05 PM, <giacomo.collini@gmail.com> wrote:
>
>> I took a look to commercial alternatives like FusionChart.
>> They are quite cheap indeed but on the other hand I would like to
>> stick to the "preference to open source components and libraries"
>> policy. So I strongly support Open Flash Charts.
>>
>> Thanks,
>>
>> On Mon, Sep 1, 2008 at 11:31 AM, Francesco Vivoli <f.vivoli@gmail.com>
>> wrote:
>> > For me they look ok. If there is some other compelling reason for yahoo
>> I'll
>> > be fine with yahoo as well.
>> > ciao
>> > F
>> >
>> > On Mon, Sep 1, 2008 at 11:19 AM, Roman Kalyakin <theorm@gmail.com>
>> wrote:
>> >>
>> >> Okay. The last thing is to decide what charts to use. I suggest if
>> >> everyone is satisfied with the look'n'feel of the open flash charts,
>> let's
>> >> go for it.
>> >>
>> >> -R
>> >>
>> >> On Mon, Sep 1, 2008 at 11:16 AM, Francesco Vivoli <f.vivoli@gmail.com>
>> >> wrote:
>> >>>
>> >>> Yes, this makes sense. After all much of the work is on the data
>> format,
>> >>> which can be reused.
>> >>> F
>> >>>
>> >>> On Mon, Sep 1, 2008 at 11:14 AM, Roman Kalyakin <theorm@gmail.com>
>> wrote:
>> >>>>
>> >>>> Taking into account the limitations of the bar charts, if we want to
>> >>>> finish the charts at once without rewriting things later, that would
>> make
>> >>>> sense to implement a polar chart from the beginning. From the other
>> side, we
>> >>>> could just drop in a swf bar chart instead of the polar chart and see
>> how it
>> >>>> looks. If we don't like it - we write a polar chart extension.
>> >>>>
>> >>>> -R
>> >>>>
>> >>>>
>> >>>> On Mon, Sep 1, 2008 at 10:05 AM, Francesco Vivoli <
>> f.vivoli@gmail.com>
>> >>>> wrote:
>> >>>>>
>> >>>>> Wrt to the polar chart, don't you think that changing it for a
>> stacked
>> >>>>> bar chart is an option.
>> >>>>> We use it because we want to display multiple datasets, where each
>> >>>>> point represent a certain quantity.
>> >>>>> In the specific we are drawing a polar line (i.e, a segmented line
>> that
>> >>>>> rounds the origin:)) for each asset group (sites or bu's).
>> >>>>> Every edge represent how much that group scored for a certain
>> >>>>> appliance, right?
>> >>>>>
>> >>>>> The problem with stacked bar charts is that each data point (an
>> >>>>> appliance for a group) is bound within [0,10], so if there are 5
>> appliances
>> >>>>> the whole bar can assume values within [0,50], with the upper value
>> >>>>> increasing with the number of appliances. This could lead to some
>> >>>>> visualization problems now that I think about it. If these SDKs
>> provide
>> >>>>> zooming, which I don't know, it would be ok though.
>> >>>>>
>> >>>>> Another possibility is to have segmented bar charts (one bar per
>> >>>>> appliance/group, grouped by group), in this case we'd have lesser
>> >>>>> variability on the y's but a much wider chart.
>> >>>>>
>> >>>>> Finally, creating a polar chart in SWF would be cool. The only issue
>> >>>>> would be that I'd like for it to be better than JFreeChart's one,
>> since
>> >>>>> right now we can't even put a label for the edges (the degrees
>> numbers are
>> >>>>> hard-coded into JFree code-_-)
>> >>>>>
>> >>>>> F
>> >>>>>
>> >>>>> On Mon, Sep 1, 2008 at 9:52 AM, Roman Kalyakin <theorm@gmail.com>
>> >>>>> wrote:
>> >>>>>>
>> >>>>>> Hi Francesco,
>> >>>>>>
>> >>>>>> Yes. Open Flash Chart improved a lot within the last year. I
>> checked
>> >>>>>> both OFC and Yahoo charts and they both don't have a polar chart.
>> That means
>> >>>>>> that we have two ways: either display this data on another type of
>> chart or
>> >>>>>> implement the polar chart on top of Open Flash Chart or Yahoo
>> charts. It
>> >>>>>> requires however some knowledge of actionscript. I took a look at
>> it though,
>> >>>>>> and it doesn't look so much different comparing to Java. So, I
>> beleive it
>> >>>>>> would be not a big deal to implement it.
>> >>>>>>
>> >>>>>> Regarding the data format: Yes, JSON is more compact. And to adopt
>> >>>>>> Atalaya data format to the charts we can either change the format
>> within the
>> >>>>>> chart or implement the xml->json converter. I think the second
>> option is
>> >>>>>> better. We could even start using data in JSON format for the UI
>> too as it
>> >>>>>> is more compact.
>> >>>>>>
>> >>>>>> What to choose. For me both are ok. Yahoo SDK seems more robust and
>> >>>>>> flexible. But it requires some coding. The fact that it's Yahoo
>> also annoys
>> >>>>>> me a bit. But since it's just an SDK with primitives and not a set
>> of charts
>> >>>>>> with yahoo logo on them, it's still a candidate.
>> >>>>>>
>> >>>>>> Cheers,
>> >>>>>> -Roman
>> >>>>>>
>> >>>>>> On Mon, Sep 1, 2008 at 9:32 AM, Francesco Vivoli <
>> f.vivoli@gmail.com>
>> >>>>>> wrote:
>> >>>>>>>
>> >>>>>>> Hi Roman
>> >>>>>>>
>> >>>>>>> I had given a look at the open flash chart thang a while ago, it
>> >>>>>>> looked good then and it seems they have improved. As for the yahoo
>> sdk, I
>> >>>>>>> don't know enough about it to make a comment.The only thing is
>> that an year
>> >>>>>>> ago we decided not to use yahoo UI nor GWT, because well, there
>> was a direct
>> >>>>>>> link to these bigbig corps... I don't know, maybe it's me who's
>> too
>> >>>>>>> skeptical.
>> >>>>>>>
>> >>>>>>> Ok, speaking from a purely technical perspective I'd say let's
>> look
>> >>>>>>> at the requirements. Right now we use time series, pie and polar
>> charts.
>> >>>>>>> While the first two are supported for sure, I'm not sure about the
>> latter.
>> >>>>>>>
>> >>>>>>> In the case we can't make polar charts well, we still can rethink
>> how
>> >>>>>>> to depict the same information: a stacked bar chart could maybe do
>> the job,
>> >>>>>>> couldn't it?
>> >>>>>>>
>> >>>>>>> Then there is data format issue. As you know, right now we produce
>> >>>>>>> XML by default which could be fed into OFC, at least before.
>> Nevertheless I
>> >>>>>>> don't think it's desiderable, JSON is much more compact as a
>> format. Beside
>> >>>>>>> that, the XML that produce is atalaya-domain specific, whereas we
>> should
>> >>>>>>> produce an OFC-specific one. Wrt we should start investigating how
>> to
>> >>>>>>> produce JSON strings from our model, i.e how to refactor the all
>> >>>>>>> ChartBuilder chain.
>> >>>>>>> What do yo guys say?
>> >>>>>>>
>> >>>>>>> ciao
>> >>>>>>> F
>> >>>>>>>
>> >>>>>>> On Fri, Aug 29, 2008 at 7:32 PM, Roman Kalyakin <theorm@gmail.com
>> >
>> >>>>>>> wrote:
>> >>>>>>>>
>> >>>>>>>> Hi,
>> >>>>>>>>
>> >>>>>>>> As we discussed one of our initial goals is to move towards nice
>> >>>>>>>> charts, possibly flash. I've been checking current situation with
>> flash
>> >>>>>>>> charts in opensource world and found this project:
>> >>>>>>>> http://teethgrinder.co.uk/open-flash-chart-2
>> >>>>>>>> I saw it before, but it used to be a charting server running on
>> php.
>> >>>>>>>> Now, in version 2 they moved towards pure SWF + JSON. The charts
>> look nice
>> >>>>>>>> and easy to use. It's GPL v2.
>> >>>>>>>>
>> >>>>>>>> There is another project that is worth attention:
>> >>>>>>>>
>> http://developer.yahoo.com/flash/astra-flash/charts/examples.html.
>> >>>>>>>> It's a Yahoo SDK for flash and is not for charts only. The SDK is
>> >>>>>>>> under BSD. The only problem is that it's not a ready made SWF
>> that reads
>> >>>>>>>> data from external file, thus it needs some flash/actionscript
>> development
>> >>>>>>>> skills. However this option is more flexible because the SDK
>> seems to
>> >>>>>>>> include a huge variety of primitives.
>> >>>>>>>>
>> >>>>>>>> What do you guys think?
>> >>>>>>>>
>> >>>>>>>> Cheers,
>> >>>>>>>> -Roman
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> -------------------------------------------------------------------------
>> >>>>>>>> This SF.Net email is sponsored by the Moblin Your Move
>> Developer's
>> >>>>>>>> challenge
>> >>>>>>>> Build the coolest Linux based applications with Moblin SDK & win
>> >>>>>>>> great prizes
>> >>>>>>>> Grand prize is a trip for two to an Open Source event anywhere in
>> >>>>>>>> the world
>> >>>>>>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> >>>>>>>> _______________________________________________
>> >>>>>>>> Atalaya-developer mailing list
>> >>>>>>>> Atalaya-developer@lists.sourceforge.net
>> >>>>>>>> https://lists.sourceforge.net/lists/listinfo/atalaya-developer
>> >>>>>>>>
>> >>>>>>>
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>
>> >
>> >
>> >
>> -------------------------------------------------------------------------
>> > This SF.Net email is sponsored by the Moblin Your Move Developer's
>> challenge
>> > Build the coolest Linux based applications with Moblin SDK & win great
>> > prizes
>> > Grand prize is a trip for two to an Open Source event anywhere in the
>> world
>> > http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> > _______________________________________________
>> > Atalaya-developer mailing list
>> > Atalaya-developer@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/atalaya-developer
>> >
>> >
>>
>>
>>
>> --
>> Giacomo Collini - CISSP
>>
>> Information Security Analyst
>>
>>
>> email: giacomo.collini@gmail.com
>> mobile: (+34)628332736
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win great
>> prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the
>> world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> Atalaya-developer mailing list
>> Atalaya-developer@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/atalaya-developer
>>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Atalaya-developer mailing list
> Atalaya-developer@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/atalaya-developer
>
>

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Atalaya-developer mailing list
Atalaya-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/atalaya-developer

More charting options

2009-03-23T08:33:30Z

I've just found this article. It might be considered an alternative to flash
charts.

http://dojotdg.zaffra.com/2009/03/dojo-now-with-drawing-tools-linux-journal-reprint/

cheers
F
------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
Atalaya-developer mailing list
Atalaya-developer@...
https://lists.sourceforge.net/lists/listinfo/atalaya-developer

Re: New ticketing system?

2008-11-11T09:45:12Z

Hello Gentlemen!
Have you considered IssueTrak software for your new ticketing system?
Please visit www.issuetrak.com for more information.
Thanks!

Francesco Vivoli wrote:

Hoi

feeling inspired I've written a blog entry with some random thoughts.
http://blogs.atalayasec.org/dev/2008/08/choosing-the-right-ticketing-system-jira-vs-trac-vs-launchpad/

Roman, I'd like to hear your opinion about what we should go for. Launchpad
is appealing to me but it means a bigger migration (especially away from
SVN:S)
cheers
F

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Atalaya-developer mailing list
Atalaya-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/atalaya-developer

CacheCorrelator

2008-11-01T03:58:08Z

Hello,

I'm committing a rudimentary cache implementation for the ScanCorrelator.
This new toy corrects a suspected incorrect behaviour of the ScanCorrelator:
if the current thread returns two scans containing two new similar elements,
both elements are saved to the database. Thanks to the CorrelatorCache the
first instance of the element is cached and all the subsequent similar
elements are replaced with the cached copy.

The CorrelatorCache reported a significative performance improvement during
tests.

--
Giacomo Collini - CISSP

Information Security Analyst

email: giacomo.collini@...
mobile: (+34)628332736
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Atalaya-developer mailing list
Atalaya-developer@...
https://lists.sourceforge.net/lists/listinfo/atalaya-developer

Continuum screwed up

2008-10-19T07:34:11Z

Hi

I'm noticing that our continuum instance on atalayasec.org is down, and I'm
having hard times restarting it...
Roman, could you have a look when you have some time? I don't remember
exactly how the setup was:)

cheers
Francesco
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Atalaya-developer mailing list
Atalaya-developer@...
https://lists.sourceforge.net/lists/listinfo/atalaya-developer

Atalaya Project

2008-10-14T14:42:06Z

Greetings,

I just became aware of your project via Sourceforge and would like to see if a subset of you would like to work on a product offerring based upon the Atlalaya framework.

I've read a bit about the project and its core intentions and I am needed to develop a product offering that caters to a specific niche within Information Security. Above and beyond assessment results from various security producs such as Nessus, Nmap, etc, I'm hoping to get Atalaya to ingest manual assesment data through some form of pre-defined format that is driven by the platform. If anyone is interested in this effort, please feel free to reach out to me in response.

Kind regards,

Tony

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Atalaya-developer mailing list
Atalaya-developer@...
https://lists.sourceforge.net/lists/listinfo/atalaya-developer

RSS feeds

2008-09-16T03:32:53Z

Hi

I've had to install a CI tool here (hudson) and I'm seeing that it makes a fairly neat use of RSS feeds.
(Background: this hudson schedules builds of projects and reports their exit status)

In particular it allows to subscribe for events at the dashboard level (every build for every project, every failed build for every project) and on a per project basis.
Thinking back to Atalaya I'm thinking of something similar where levels are what we have now, i.e:

-dashboard
-groups
-hosts

and where the events are the updates. The only tricky part is to define a consistent set of URIs so that someone can subscribe to selected feeds.

Giacomo: I'm not proposing to rework the schedule, just build up a backlog. for it to be useful we should discuss whethere a feature like this is useful/desiderable...

Up?
F

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Atalaya-developer mailing list
Atalaya-developer@...
https://lists.sourceforge.net/lists/listinfo/atalaya-developer

Re: Using Treemaps for data visualization?

2008-09-13T01:03:33Z

well,

if the objective is to induce violent headaches I think tree maps are just perfect,
I think that it might be useful to introduce a tree menu in order to rationalize tables hierarchy and ease navigation between them. Nevertheless I suggest to focus on the agreed development plan before introducing new elements to it.

Ciao

On Fri, Sep 12, 2008 at 9:25 PM, Roman Kalyakin <theorm@...> wrote:

Hi,

This reminded me of The Map Of The Internet (c). :)
http://xkcd.com/195/

Frankly, that looks interesting, especially since there is a java implementation already. I doubt it's possible to eliminate all tables. But that would work at least as an alternative way of representing data.

-Roman

On Thu, Sep 11, 2008 at 7:31 PM, Francesco Vivoli <f.vivoli@...> wrote:

Hi all

I don't know if you guys had the chance of reading this blog post: http://radajo.blogspot.com/2008/09/security-book-review-applied-security.html .In case not a short cite:

"Although we (infosec pros) are familiarized with link graphs to represent relationships between botnet members or hosts, the book provides a whole set of charts for different purposes; one of the most useful types, and we are not very used too it in the security field, is treemaps."

I've read a bit here and there and I found them a neat way of displaying multi-variate datasets. You can find the main page at: http://www.cs.umd.edu/hcil/treemap-history/

For the impatients: there's an OS java implementation of the main algorithms.
At least I think this topic deserves a bit of study, I've a gut feeling that we might be able to get rid of boring tables if correctly planned:)

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Atalaya-developer mailing list
Atalaya-developer@...
https://lists.sourceforge.net/lists/listinfo/atalaya-developer

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Atalaya-developer mailing list
Atalaya-developer@...
https://lists.sourceforge.net/lists/listinfo/atalaya-developer

--
Giacomo Collini - CISSP

Information Security Analyst

email: giacomo.collini@...
mobile: (+34)628332736

Re: Using Treemaps for data visualization?

2008-09-12T13:25:14Z

Hi,

This reminded me of The Map Of The Internet (c). :)
http://xkcd.com/195/

Frankly, that looks interesting, especially since there is a java implementation already. I doubt it's possible to eliminate all tables. But that would work at least as an alternative way of representing data.

-Roman

On Thu, Sep 11, 2008 at 7:31 PM, Francesco Vivoli <f.vivoli@...> wrote:

Hi all

I don't know if you guys had the chance of reading this blog post: http://radajo.blogspot.com/2008/09/security-book-review-applied-security.html .In case not a short cite:

"Although we (infosec pros) are familiarized with link graphs to represent relationships between botnet members or hosts, the book provides a whole set of charts for different purposes; one of the most useful types, and we are not very used too it in the security field, is treemaps."

I've read a bit here and there and I found them a neat way of displaying multi-variate datasets. You can find the main page at: http://www.cs.umd.edu/hcil/treemap-history/

For the impatients: there's an OS java implementation of the main algorithms.
At least I think this topic deserves a bit of study, I've a gut feeling that we might be able to get rid of boring tables if correctly planned:)

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Atalaya-developer mailing list
Atalaya-developer@...
https://lists.sourceforge.net/lists/listinfo/atalaya-developer

Re: Using Treemaps for data visualization?

2008-09-11T11:09:22Z

Follow up for the Russian-speaking:)

Voronoi treemaps for the visualization of software metrics
http://portal.acm.org/citation.cfm?id=1056018.1056041

a special case of http://en.wikipedia.org/wiki/Voronoi_diagram

cheers
F

On Thu, Sep 11, 2008 at 7:31 PM, Francesco Vivoli <f.vivoli@...> wrote:

Hi all

I don't know if you guys had the chance of reading this blog post: http://radajo.blogspot.com/2008/09/security-book-review-applied-security.html .In case not a short cite:

"Although we (infosec pros) are familiarized with link graphs to represent relationships between botnet members or hosts, the book provides a whole set of charts for different purposes; one of the most useful types, and we are not very used too it in the security field, is treemaps."

I've read a bit here and there and I found them a neat way of displaying multi-variate datasets. You can find the main page at: http://www.cs.umd.edu/hcil/treemap-history/

For the impatients: there's an OS java implementation of the main algorithms.
At least I think this topic deserves a bit of study, I've a gut feeling that we might be able to get rid of boring tables if correctly planned:)

Using Treemaps for data visualization?

2008-09-11T10:31:12Z

Hi all

I don't know if you guys had the chance of reading this blog post: http://radajo.blogspot.com/2008/09/security-book-review-applied-security.html .In case not a short cite:

"Although we (infosec pros) are familiarized with link graphs to represent relationships between botnet members or hosts, the book provides a whole set of charts for different purposes; one of the most useful types, and we are not very used too it in the security field, is treemaps."

I've read a bit here and there and I found them a neat way of displaying multi-variate datasets. You can find the main page at: http://www.cs.umd.edu/hcil/treemap-history/

For the impatients: there's an OS java implementation of the main algorithms.
At least I think this topic deserves a bit of study, I've a gut feeling that we might be able to get rid of boring tables if correctly planned:)

Re: Flash charts

2008-09-08T00:38:58Z

nice!

On Mon, Sep 8, 2008 at 12:34 AM, Roman Kalyakin <theorm@...> wrote:

Hi there,

Work is going on and there are the first results for those who want to improve motivation. :)
See attached screenshot.

Cheers,
Roman

On Mon, Sep 1, 2008 at 5:05 PM, <giacomo.collini@...> wrote:

I took a look to commercial alternatives like FusionChart.
They are quite cheap indeed but on the other hand I would like to
stick to the "preference to open source components and libraries"
policy. So I strongly support Open Flash Charts.

Thanks,

On Mon, Sep 1, 2008 at 11:31 AM, Francesco Vivoli <f.vivoli@...> wrote:
> For me they look ok. If there is some other compelling reason for yahoo I'll
> be fine with yahoo as well.
> ciao
> F
>
> On Mon, Sep 1, 2008 at 11:19 AM, Roman Kalyakin <theorm@...> wrote:
>>
>> Okay. The last thing is to decide what charts to use. I suggest if
>> everyone is satisfied with the look'n'feel of the open flash charts, let's
>> go for it.
>>
>> -R
>>
>> On Mon, Sep 1, 2008 at 11:16 AM, Francesco Vivoli <f.vivoli@...>
>> wrote:
>>>
>>> Yes, this makes sense. After all much of the work is on the data format,
>>> which can be reused.
>>> F
>>>
>>> On Mon, Sep 1, 2008 at 11:14 AM, Roman Kalyakin <theorm@...> wrote:
>>>>
>>>> Taking into account the limitations of the bar charts, if we want to
>>>> finish the charts at once without rewriting things later, that would make
>>>> sense to implement a polar chart from the beginning. From the other side, we
>>>> could just drop in a swf bar chart instead of the polar chart and see how it
>>>> looks. If we don't like it - we write a polar chart extension.
>>>>
>>>> -R
>>>>
>>>>
>>>> On Mon, Sep 1, 2008 at 10:05 AM, Francesco Vivoli <f.vivoli@...>
>>>> wrote:
>>>>>
>>>>> Wrt to the polar chart, don't you think that changing it for a stacked
>>>>> bar chart is an option.
>>>>> We use it because we want to display multiple datasets, where each
>>>>> point represent a certain quantity.
>>>>> In the specific we are drawing a polar line (i.e, a segmented line that
>>>>> rounds the origin:)) for each asset group (sites or bu's).
>>>>> Every edge represent how much that group scored for a certain
>>>>> appliance, right?
>>>>>
>>>>> The problem with stacked bar charts is that each data point (an
>>>>> appliance for a group) is bound within [0,10], so if there are 5 appliances
>>>>> the whole bar can assume values within [0,50], with the upper value
>>>>> increasing with the number of appliances. This could lead to some
>>>>> visualization problems now that I think about it. If these SDKs provide
>>>>> zooming, which I don't know, it would be ok though.
>>>>>
>>>>> Another possibility is to have segmented bar charts (one bar per
>>>>> appliance/group, grouped by group), in this case we'd have lesser
>>>>> variability on the y's but a much wider chart.
>>>>>
>>>>> Finally, creating a polar chart in SWF would be cool. The only issue
>>>>> would be that I'd like for it to be better than JFreeChart's one, since
>>>>> right now we can't even put a label for the edges (the degrees numbers are
>>>>> hard-coded into JFree code-_-)
>>>>>
>>>>> F
>>>>>
>>>>> On Mon, Sep 1, 2008 at 9:52 AM, Roman Kalyakin <theorm@...>
>>>>> wrote:
>>>>>>
>>>>>> Hi Francesco,
>>>>>>
>>>>>> Yes. Open Flash Chart improved a lot within the last year. I checked
>>>>>> both OFC and Yahoo charts and they both don't have a polar chart. That means
>>>>>> that we have two ways: either display this data on another type of chart or
>>>>>> implement the polar chart on top of Open Flash Chart or Yahoo charts. It
>>>>>> requires however some knowledge of actionscript. I took a look at it though,
>>>>>> and it doesn't look so much different comparing to Java. So, I beleive it
>>>>>> would be not a big deal to implement it.
>>>>>>
>>>>>> Regarding the data format: Yes, JSON is more compact. And to adopt
>>>>>> Atalaya data format to the charts we can either change the format within the
>>>>>> chart or implement the xml->json converter. I think the second option is
>>>>>> better. We could even start using data in JSON format for the UI too as it
>>>>>> is more compact.
>>>>>>
>>>>>> What to choose. For me both are ok. Yahoo SDK seems more robust and
>>>>>> flexible. But it requires some coding. The fact that it's Yahoo also annoys
>>>>>> me a bit. But since it's just an SDK with primitives and not a set of charts
>>>>>> with yahoo logo on them, it's still a candidate.
>>>>>>
>>>>>> Cheers,
>>>>>> -Roman
>>>>>>
>>>>>> On Mon, Sep 1, 2008 at 9:32 AM, Francesco Vivoli <f.vivoli@...>
>>>>>> wrote:
>>>>>>>
>>>>>>> Hi Roman
>>>>>>>
>>>>>>> I had given a look at the open flash chart thang a while ago, it
>>>>>>> looked good then and it seems they have improved. As for the yahoo sdk, I
>>>>>>> don't know enough about it to make a comment.The only thing is that an year
>>>>>>> ago we decided not to use yahoo UI nor GWT, because well, there was a direct
>>>>>>> link to these bigbig corps... I don't know, maybe it's me who's too
>>>>>>> skeptical.
>>>>>>>
>>>>>>> Ok, speaking from a purely technical perspective I'd say let's look
>>>>>>> at the requirements. Right now we use time series, pie and polar charts.
>>>>>>> While the first two are supported for sure, I'm not sure about the latter.
>>>>>>>
>>>>>>> In the case we can't make polar charts well, we still can rethink how
>>>>>>> to depict the same information: a stacked bar chart could maybe do the job,
>>>>>>> couldn't it?
>>>>>>>
>>>>>>> Then there is data format issue. As you know, right now we produce
>>>>>>> XML by default which could be fed into OFC, at least before. Nevertheless I
>>>>>>> don't think it's desiderable, JSON is much more compact as a format. Beside
>>>>>>> that, the XML that produce is atalaya-domain specific, whereas we should
>>>>>>> produce an OFC-specific one. Wrt we should start investigating how to
>>>>>>> produce JSON strings from our model, i.e how to refactor the all
>>>>>>> ChartBuilder chain.
>>>>>>> What do yo guys say?
>>>>>>>
>>>>>>> ciao
>>>>>>> F
>>>>>>>
>>>>>>> On Fri, Aug 29, 2008 at 7:32 PM, Roman Kalyakin <theorm@...>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> As we discussed one of our initial goals is to move towards nice
>>>>>>>> charts, possibly flash. I've been checking current situation with flash
>>>>>>>> charts in opensource world and found this project:
>>>>>>>> http://teethgrinder.co.uk/open-flash-chart-2
>>>>>>>> I saw it before, but it used to be a charting server running on php.
>>>>>>>> Now, in version 2 they moved towards pure SWF + JSON. The charts look nice
>>>>>>>> and easy to use. It's GPL v2.
>>>>>>>>
>>>>>>>> There is another project that is worth attention:
>>>>>>>> http://developer.yahoo.com/flash/astra-flash/charts/examples.html.
>>>>>>>> It's a Yahoo SDK for flash and is not for charts only. The SDK is
>>>>>>>> under BSD. The only problem is that it's not a ready made SWF that reads
>>>>>>>> data from external file, thus it needs some flash/actionscript development
>>>>>>>> skills. However this option is more flexible because the SDK seems to
>>>>>>>> include a huge variety of primitives.
>>>>>>>>
>>>>>>>> What do you guys think?
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> -Roman
>>>>>>>>
>>>>>>>>
>>>>>>>> -------------------------------------------------------------------------
>>>>>>>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>>>>>>>> challenge
>>>>>>>> Build the coolest Linux based applications with Moblin SDK & win
>>>>>>>> great prizes
>>>>>>>> Grand prize is a trip for two to an Open Source event anywhere in
>>>>>>>> the world
>>>>>>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>>>>>>> _______________________________________________
>>>>>>>> Atalaya-developer mailing list
>>>>>>>> Atalaya-developer@...
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/atalaya-developer
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Atalaya-developer mailing list
> Atalaya-developer@...
> https://lists.sourceforge.net/lists/listinfo/atalaya-developer
>
>

--
Giacomo Collini - CISSP

Information Security Analyst

email: giacomo.collini@...
mobile: (+34)628332736

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Atalaya-developer mailing list
Atalaya-developer@...
https://lists.sourceforge.net/lists/listinfo/atalaya-developer

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Atalaya-developer mailing list
Atalaya-developer@...
https://lists.sourceforge.net/lists/listinfo/atalaya-developer

Re: Flash charts

2008-09-07T15:34:00Z

Hi there,

Work is going on and there are the first results for those who want to improve motivation. :)
See attached screenshot.

Cheers,
Roman

On Mon, Sep 1, 2008 at 5:05 PM, <giacomo.collini@...> wrote:

I took a look to commercial alternatives like FusionChart.
They are quite cheap indeed but on the other hand I would like to
stick to the "preference to open source components and libraries"
policy. So I strongly support Open Flash Charts.

Thanks,

On Mon, Sep 1, 2008 at 11:31 AM, Francesco Vivoli <f.vivoli@...> wrote:
> For me they look ok. If there is some other compelling reason for yahoo I'll
> be fine with yahoo as well.
> ciao
> F
>
> On Mon, Sep 1, 2008 at 11:19 AM, Roman Kalyakin <theorm@...> wrote:
>>
>> Okay. The last thing is to decide what charts to use. I suggest if
>> everyone is satisfied with the look'n'feel of the open flash charts, let's
>> go for it.
>>
>> -R
>>
>> On Mon, Sep 1, 2008 at 11:16 AM, Francesco Vivoli <f.vivoli@...>
>> wrote:
>>>
>>> Yes, this makes sense. After all much of the work is on the data format,
>>> which can be reused.
>>> F
>>>
>>> On Mon, Sep 1, 2008 at 11:14 AM, Roman Kalyakin <theorm@...> wrote:
>>>>
>>>> Taking into account the limitations of the bar charts, if we want to
>>>> finish the charts at once without rewriting things later, that would make
>>>> sense to implement a polar chart from the beginning. From the other side, we
>>>> could just drop in a swf bar chart instead of the polar chart and see how it
>>>> looks. If we don't like it - we write a polar chart extension.
>>>>
>>>> -R
>>>>
>>>>
>>>> On Mon, Sep 1, 2008 at 10:05 AM, Francesco Vivoli <f.vivoli@...>
>>>> wrote:
>>>>>
>>>>> Wrt to the polar chart, don't you think that changing it for a stacked
>>>>> bar chart is an option.
>>>>> We use it because we want to display multiple datasets, where each
>>>>> point represent a certain quantity.
>>>>> In the specific we are drawing a polar line (i.e, a segmented line that
>>>>> rounds the origin:)) for each asset group (sites or bu's).
>>>>> Every edge represent how much that group scored for a certain
>>>>> appliance, right?
>>>>>
>>>>> The problem with stacked bar charts is that each data point (an
>>>>> appliance for a group) is bound within [0,10], so if there are 5 appliances
>>>>> the whole bar can assume values within [0,50], with the upper value
>>>>> increasing with the number of appliances. This could lead to some
>>>>> visualization problems now that I think about it. If these SDKs provide
>>>>> zooming, which I don't know, it would be ok though.
>>>>>
>>>>> Another possibility is to have segmented bar charts (one bar per
>>>>> appliance/group, grouped by group), in this case we'd have lesser
>>>>> variability on the y's but a much wider chart.
>>>>>
>>>>> Finally, creating a polar chart in SWF would be cool. The only issue
>>>>> would be that I'd like for it to be better than JFreeChart's one, since
>>>>> right now we can't even put a label for the edges (the degrees numbers are
>>>>> hard-coded into JFree code-_-)
>>>>>
>>>>> F
>>>>>
>>>>> On Mon, Sep 1, 2008 at 9:52 AM, Roman Kalyakin <theorm@...>
>>>>> wrote:
>>>>>>
>>>>>> Hi Francesco,
>>>>>>
>>>>>> Yes. Open Flash Chart improved a lot within the last year. I checked
>>>>>> both OFC and Yahoo charts and they both don't have a polar chart. That means
>>>>>> that we have two ways: either display this data on another type of chart or
>>>>>> implement the polar chart on top of Open Flash Chart or Yahoo charts. It
>>>>>> requires however some knowledge of actionscript. I took a look at it though,
>>>>>> and it doesn't look so much different comparing to Java. So, I beleive it
>>>>>> would be not a big deal to implement it.
>>>>>>
>>>>>> Regarding the data format: Yes, JSON is more compact. And to adopt
>>>>>> Atalaya data format to the charts we can either change the format within the
>>>>>> chart or implement the xml->json converter. I think the second option is
>>>>>> better. We could even start using data in JSON format for the UI too as it
>>>>>> is more compact.
>>>>>>
>>>>>> What to choose. For me both are ok. Yahoo SDK seems more robust and
>>>>>> flexible. But it requires some coding. The fact that it's Yahoo also annoys
>>>>>> me a bit. But since it's just an SDK with primitives and not a set of charts
>>>>>> with yahoo logo on them, it's still a candidate.
>>>>>>
>>>>>> Cheers,
>>>>>> -Roman
>>>>>>
>>>>>> On Mon, Sep 1, 2008 at 9:32 AM, Francesco Vivoli <f.vivoli@...>
>>>>>> wrote:
>>>>>>>
>>>>>>> Hi Roman
>>>>>>>
>>>>>>> I had given a look at the open flash chart thang a while ago, it
>>>>>>> looked good then and it seems they have improved. As for the yahoo sdk, I
>>>>>>> don't know enough about it to make a comment.The only thing is that an year
>>>>>>> ago we decided not to use yahoo UI nor GWT, because well, there was a direct
>>>>>>> link to these bigbig corps... I don't know, maybe it's me who's too
>>>>>>> skeptical.
>>>>>>>
>>>>>>> Ok, speaking from a purely technical perspective I'd say let's look
>>>>>>> at the requirements. Right now we use time series, pie and polar charts.
>>>>>>> While the first two are supported for sure, I'm not sure about the latter.
>>>>>>>
>>>>>>> In the case we can't make polar charts well, we still can rethink how
>>>>>>> to depict the same information: a stacked bar chart could maybe do the job,
>>>>>>> couldn't it?
>>>>>>>
>>>>>>> Then there is data format issue. As you know, right now we produce
>>>>>>> XML by default which could be fed into OFC, at least before. Nevertheless I
>>>>>>> don't think it's desiderable, JSON is much more compact as a format. Beside
>>>>>>> that, the XML that produce is atalaya-domain specific, whereas we should
>>>>>>> produce an OFC-specific one. Wrt we should start investigating how to
>>>>>>> produce JSON strings from our model, i.e how to refactor the all
>>>>>>> ChartBuilder chain.
>>>>>>> What do yo guys say?
>>>>>>>
>>>>>>> ciao
>>>>>>> F
>>>>>>>
>>>>>>> On Fri, Aug 29, 2008 at 7:32 PM, Roman Kalyakin <theorm@...>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> As we discussed one of our initial goals is to move towards nice
>>>>>>>> charts, possibly flash. I've been checking current situation with flash
>>>>>>>> charts in opensource world and found this project:
>>>>>>>> http://teethgrinder.co.uk/open-flash-chart-2
>>>>>>>> I saw it before, but it used to be a charting server running on php.
>>>>>>>> Now, in version 2 they moved towards pure SWF + JSON. The charts look nice
>>>>>>>> and easy to use. It's GPL v2.
>>>>>>>>
>>>>>>>> There is another project that is worth attention:
>>>>>>>> http://developer.yahoo.com/flash/astra-flash/charts/examples.html.
>>>>>>>> It's a Yahoo SDK for flash and is not for charts only. The SDK is
>>>>>>>> under BSD. The only problem is that it's not a ready made SWF that reads
>>>>>>>> data from external file, thus it needs some flash/actionscript development
>>>>>>>> skills. However this option is more flexible because the SDK seems to
>>>>>>>> include a huge variety of primitives.
>>>>>>>>
>>>>>>>> What do you guys think?
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> -Roman
>>>>>>>>
>>>>>>>>
>>>>>>>> -------------------------------------------------------------------------
>>>>>>>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>>>>>>>> challenge
>>>>>>>> Build the coolest Linux based applications with Moblin SDK & win
>>>>>>>> great prizes
>>>>>>>> Grand prize is a trip for two to an Open Source event anywhere in
>>>>>>>> the world
>>>>>>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>>>>>>> _______________________________________________
>>>>>>>> Atalaya-developer mailing list
>>>>>>>> Atalaya-developer@...
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/atalaya-developer
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Atalaya-developer mailing list
> Atalaya-developer@...
> https://lists.sourceforge.net/lists/listinfo/atalaya-developer
>
>

--
Giacomo Collini - CISSP

Information Security Analyst

email: giacomo.collini@...
mobile: (+34)628332736

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Atalaya-developer mailing list
Atalaya-developer@...
https://lists.sourceforge.net/lists/listinfo/atalaya-developer

s.png (171K) Download Attachment

Re: 1st Atalaya meeting minutes

2008-09-04T13:04:04Z

Hi,

I agree with Francesco that we can postpone with migration until we reach a consensus or get tired of SF tracker.
Meanwhile, I started working on Flash charts, according to the defined priorities.

-Roman

On Wed, Sep 3, 2008 at 11:25 PM, Francesco Vivoli <f.vivoli@...> wrote:

Hi

after some discussion about some of the tasks listed below, it might be time to see whether the priorities are really what we first agreed on.

In particular I think that we agree that while a nice-to-have, migrating the tracker from SF doesn't make the project move ahead a lot. Flash charts do instead, as they improve the look and feel a lot.

Another piece that we have overlooked so far is SCM. With this I mean at least to make so that someone can develop an appliance without having to rebuild the whole codebase. Same goes for implementations of bindings of new ticketing systems.

Well, ok this might go on another thread, I was just trying to make a point here:)
cheers
F

On Fri, Aug 1, 2008 at 7:48 PM, Francesco Vivoli <f.vivoli@...> wrote:

Hi everybody

as promised here go the minutes of what we said between on tinto and the other:)
(and btw, I think there should be shifts for whom does the note keeping)

List of high level features (+'s for priorities)

1- reporting(-): agreed to remove the current impl and to rethink the whole thing.

2- UI(++):
   - make it smoother (cut rough edges, clutchy actions and the like)
   - fix bugs
   - improve charts (flash?)

3-plugins(+):
   - how to develop, i.e the API and also providing some basic declarative configuration mean
     (many plugins only differ for a regex...)
   - lifecycle: how to configure/deconfigure and load/unload them

4- error handling and reporting(++): be more descrptive when some updates fail

5- configuration management(+):
   - initial setup (user side)
   - for developers (what they need to import to develop plugins - see the API stuff)
   - for the project (setup TRAC and migrate from SF bug tracker)

6-issues repository(++): this means re-activating corration between security elements)

7-policies(++): finish this first impl across the appliance set

8-false positives(++): finish this first impl across the appliance set

9-XML API(+) : draft design

10-MSBA(++): implement

11-testing(): evaluate what makes sense to be tested with Selenium

Now, speaking of assignments, I think that Giacomo can easily carry on what he was doing, that is
7,8 and 10. Then I can get on 4, 6 and part of 2. Roman, as you see you've got plenty of speculative
work ahead (:)) but IMO 2.3 and 5.3 should be given priority. Then the rest of 5 would be great to
have, since it also eases our daily work. Once these things are done I'm eager to see how we
can tackle the plugin matter:)

well, friday - 19:47...I think this's enough, I'm offff!
ciao
F

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Atalaya-developer mailing list
Atalaya-developer@...
https://lists.sourceforge.net/lists/listinfo/atalaya-developer

Re: 1st Atalaya meeting minutes

2008-09-03T14:25:10Z

Hi

after some discussion about some of the tasks listed below, it might be time to see whether the priorities are really what we first agreed on.

In particular I think that we agree that while a nice-to-have, migrating the tracker from SF doesn't make the project move ahead a lot. Flash charts do instead, as they improve the look and feel a lot.

Another piece that we have overlooked so far is SCM. With this I mean at least to make so that someone can develop an appliance without having to rebuild the whole codebase. Same goes for implementations of bindings of new ticketing systems.

Well, ok this might go on another thread, I was just trying to make a point here:)
cheers
F

On Fri, Aug 1, 2008 at 7:48 PM, Francesco Vivoli <f.vivoli@...> wrote:

Hi everybody

as promised here go the minutes of what we said between on tinto and the other:)
(and btw, I think there should be shifts for whom does the note keeping)

List of high level features (+'s for priorities)

1- reporting(-): agreed to remove the current impl and to rethink the whole thing.

2- UI(++):
   - make it smoother (cut rough edges, clutchy actions and the like)
   - fix bugs
   - improve charts (flash?)

3-plugins(+):
   - how to develop, i.e the API and also providing some basic declarative configuration mean
     (many plugins only differ for a regex...)
   - lifecycle: how to configure/deconfigure and load/unload them

4- error handling and reporting(++): be more descrptive when some updates fail

5- configuration management(+):
   - initial setup (user side)
   - for developers (what they need to import to develop plugins - see the API stuff)
   - for the project (setup TRAC and migrate from SF bug tracker)

6-issues repository(++): this means re-activating corration between security elements)

7-policies(++): finish this first impl across the appliance set

8-false positives(++): finish this first impl across the appliance set

9-XML API(+) : draft design

10-MSBA(++): implement

11-testing(): evaluate what makes sense to be tested with Selenium

Now, speaking of assignments, I think that Giacomo can easily carry on what he was doing, that is
7,8 and 10. Then I can get on 4, 6 and part of 2. Roman, as you see you've got plenty of speculative
work ahead (:)) but IMO 2.3 and 5.3 should be given priority. Then the rest of 5 would be great to
have, since it also eases our daily work. Once these things are done I'm eager to see how we
can tackle the plugin matter:)

well, friday - 19:47...I think this's enough, I'm offff!
ciao
F

Re: New ticketing system?

2008-09-02T01:54:36Z

Not considering functionality, I think that a hosted solution better
fits our actual team configuration.
I don't think we have time to spend in development overhead; I
understand that there has been some displease about SF ticketing
system, expecially from myself; in any case the worst problem has been
laziness; once mitigated that (thanks Francesco) it didn't take so
much to cleanup bugs queue for instance.

I would stick to SF for the moment.

On Mon, Sep 1, 2008 at 11:41 PM, Francesco Vivoli <f.vivoli@...> wrote:

> HI
>
> since we are starting to have some concrete activity, wouldn't be best if we
> made up our minds and to get along once and for all?
> Giacomo, although you might not have much of experience with this issue,
> could you maybe make up a point about hosted vs in house?
> To me hosted=(less maintenance, less traffic but also less control) while in
> house=(more maintenance, more traffic thus more $$ if we move to hosting but
> also greater control ).
>
> Now, even if we move to some hosting service, we could maintain the dev
> server to our facilities. As for the control, it's kind of clear but at the
> same time I'm not sure of which benefits we could derive from such a plus...
>
> ideas?
> F
>
> On Fri, Aug 29, 2008 at 11:43 AM, <giacomo.collini@...> wrote:
>>
>> On Thu, Aug 28, 2008 at 11:52 AM, Roman Kalyakin <theorm@...> wrote:
>> > cut
>> > Conclusion: I would give launchpad a try. It's robust and doesn't seem
>> > to
>> > disappear within the following two years. If not, then Jira is a better
>> > option than Trac. They both do not have a hosted option, and the rest of
>> > pros and cons speak for Jira.
>> >
>>
>> Hi guys,
>>
>> As I don't have a considerable experience on these platforms I don't
>> have a strong opinion. For sure the effort of migrating to a new
>> platform is compensate by the cumbersomeness of SF ticketing system.
>>
>> I will support any decision the team will take.
>>
>> Thanks
>>
>>
>> --
>> Giacomo Collini - CISSP
>>
>> Information Security Analyst
>>
>>
>> email: giacomo.collini@...
>> mobile: (+34)628332736
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win great
>> prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the
>> world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> Atalaya-developer mailing list
>> Atalaya-developer@...
>> https://lists.sourceforge.net/lists/listinfo/atalaya-developer
>
>

--
Giacomo Collini - CISSP

Information Security Analyst

email: giacomo.collini@...
mobile: (+34)628332736

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Atalaya-developer mailing list
Atalaya-developer@...
https://lists.sourceforge.net/lists/listinfo/atalaya-developer

Re: New ticketing system?

2008-09-01T14:41:02Z

HI

since we are starting to have some concrete activity, wouldn't be best if we made up our minds and to get along once and for all?
Giacomo, although you might not have much of experience with this issue, could you maybe make up a point about hosted vs in house?
To me hosted=(less maintenance, less traffic but also less control) while in house=(more maintenance, more traffic thus more $$ if we move to hosting but also greater control ).

Now, even if we move to some hosting service, we could maintain the dev server to our facilities. As for the control, it's kind of clear but at the same time I'm not sure of which benefits we could derive from such a plus...

ideas?
F

On Fri, Aug 29, 2008 at 11:43 AM, <giacomo.collini@...> wrote:

On Thu, Aug 28, 2008 at 11:52 AM, Roman Kalyakin <theorm@...> wrote:
> cut

> Conclusion: I would give launchpad a try. It's robust and doesn't seem to
> disappear within the following two years. If not, then Jira is a better
> option than Trac. They both do not have a hosted option, and the rest of
> pros and cons speak for Jira.
>

Hi guys,

As I don't have a considerable experience on these platforms I don't
have a strong opinion. For sure the effort of migrating to a new
platform is compensate by the cumbersomeness of SF ticketing system.

I will support any decision the team will take.

Thanks

--
Giacomo Collini - CISSP

Information Security Analyst

email: giacomo.collini@...
mobile: (+34)628332736

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Atalaya-developer mailing list
Atalaya-developer@...
https://lists.sourceforge.net/lists/listinfo/atalaya-developer

Re: Flash charts

2008-09-01T08:10:42Z

So do I:)

On Mon, Sep 1, 2008 at 5:05 PM, <giacomo.collini@...> wrote:

I took a look to commercial alternatives like FusionChart.
They are quite cheap indeed but on the other hand I would like to
stick to the "preference to open source components and libraries"
policy. So I strongly support Open Flash Charts.

Thanks,

On Mon, Sep 1, 2008 at 11:31 AM, Francesco Vivoli <f.vivoli@...> wrote:
> For me they look ok. If there is some other compelling reason for yahoo I'll
> be fine with yahoo as well.
> ciao
> F
>
> On Mon, Sep 1, 2008 at 11:19 AM, Roman Kalyakin <theorm@...> wrote:
>>
>> Okay. The last thing is to decide what charts to use. I suggest if
>> everyone is satisfied with the look'n'feel of the open flash charts, let's
>> go for it.
>>
>> -R
>>
>> On Mon, Sep 1, 2008 at 11:16 AM, Francesco Vivoli <f.vivoli@...>
>> wrote:
>>>
>>> Yes, this makes sense. After all much of the work is on the data format,
>>> which can be reused.
>>> F
>>>
>>> On Mon, Sep 1, 2008 at 11:14 AM, Roman Kalyakin <theorm@...> wrote:
>>>>
>>>> Taking into account the limitations of the bar charts, if we want to
>>>> finish the charts at once without rewriting things later, that would make
>>>> sense to implement a polar chart from the beginning. From the other side, we
>>>> could just drop in a swf bar chart instead of the polar chart and see how it
>>>> looks. If we don't like it - we write a polar chart extension.
>>>>
>>>> -R
>>>>
>>>>
>>>> On Mon, Sep 1, 2008 at 10:05 AM, Francesco Vivoli <f.vivoli@...>
>>>> wrote:
>>>>>
>>>>> Wrt to the polar chart, don't you think that changing it for a stacked
>>>>> bar chart is an option.
>>>>> We use it because we want to display multiple datasets, where each
>>>>> point represent a certain quantity.
>>>>> In the specific we are drawing a polar line (i.e, a segmented line that
>>>>> rounds the origin:)) for each asset group (sites or bu's).
>>>>> Every edge represent how much that group scored for a certain
>>>>> appliance, right?
>>>>>
>>>>> The problem with stacked bar charts is that each data point (an
>>>>> appliance for a group) is bound within [0,10], so if there are 5 appliances
>>>>> the whole bar can assume values within [0,50], with the upper value
>>>>> increasing with the number of appliances. This could lead to some
>>>>> visualization problems now that I think about it. If these SDKs provide
>>>>> zooming, which I don't know, it would be ok though.
>>>>>
>>>>> Another possibility is to have segmented bar charts (one bar per
>>>>> appliance/group, grouped by group), in this case we'd have lesser
>>>>> variability on the y's but a much wider chart.
>>>>>
>>>>> Finally, creating a polar chart in SWF would be cool. The only issue
>>>>> would be that I'd like for it to be better than JFreeChart's one, since
>>>>> right now we can't even put a label for the edges (the degrees numbers are
>>>>> hard-coded into JFree code-_-)
>>>>>
>>>>> F
>>>>>
>>>>> On Mon, Sep 1, 2008 at 9:52 AM, Roman Kalyakin <theorm@...>
>>>>> wrote:
>>>>>>
>>>>>> Hi Francesco,
>>>>>>
>>>>>> Yes. Open Flash Chart improved a lot within the last year. I checked
>>>>>> both OFC and Yahoo charts and they both don't have a polar chart. That means
>>>>>> that we have two ways: either display this data on another type of chart or
>>>>>> implement the polar chart on top of Open Flash Chart or Yahoo charts. It
>>>>>> requires however some knowledge of actionscript. I took a look at it though,
>>>>>> and it doesn't look so much different comparing to Java. So, I beleive it
>>>>>> would be not a big deal to implement it.
>>>>>>
>>>>>> Regarding the data format: Yes, JSON is more compact. And to adopt
>>>>>> Atalaya data format to the charts we can either change the format within the
>>>>>> chart or implement the xml->json converter. I think the second option is
>>>>>> better. We could even start using data in JSON format for the UI too as it
>>>>>> is more compact.
>>>>>>
>>>>>> What to choose. For me both are ok. Yahoo SDK seems more robust and
>>>>>> flexible. But it requires some coding. The fact that it's Yahoo also annoys
>>>>>> me a bit. But since it's just an SDK with primitives and not a set of charts
>>>>>> with yahoo logo on them, it's still a candidate.
>>>>>>
>>>>>> Cheers,
>>>>>> -Roman
>>>>>>
>>>>>> On Mon, Sep 1, 2008 at 9:32 AM, Francesco Vivoli <f.vivoli@...>
>>>>>> wrote:
>>>>>>>
>>>>>>> Hi Roman
>>>>>>>
>>>>>>> I had given a look at the open flash chart thang a while ago, it
>>>>>>> looked good then and it seems they have improved. As for the yahoo sdk, I
>>>>>>> don't know enough about it to make a comment.The only thing is that an year
>>>>>>> ago we decided not to use yahoo UI nor GWT, because well, there was a direct
>>>>>>> link to these bigbig corps... I don't know, maybe it's me who's too
>>>>>>> skeptical.
>>>>>>>
>>>>>>> Ok, speaking from a purely technical perspective I'd say let's look
>>>>>>> at the requirements. Right now we use time series, pie and polar charts.
>>>>>>> While the first two are supported for sure, I'm not sure about the latter.
>>>>>>>
>>>>>>> In the case we can't make polar charts well, we still can rethink how
>>>>>>> to depict the same information: a stacked bar chart could maybe do the job,
>>>>>>> couldn't it?
>>>>>>>
>>>>>>> Then there is data format issue. As you know, right now we produce
>>>>>>> XML by default which could be fed into OFC, at least before. Nevertheless I
>>>>>>> don't think it's desiderable, JSON is much more compact as a format. Beside
>>>>>>> that, the XML that produce is atalaya-domain specific, whereas we should
>>>>>>> produce an OFC-specific one. Wrt we should start investigating how to
>>>>>>> produce JSON strings from our model, i.e how to refactor the all
>>>>>>> ChartBuilder chain.
>>>>>>> What do yo guys say?
>>>>>>>
>>>>>>> ciao
>>>>>>> F
>>>>>>>
>>>>>>> On Fri, Aug 29, 2008 at 7:32 PM, Roman Kalyakin <theorm@...>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> As we discussed one of our initial goals is to move towards nice
>>>>>>>> charts, possibly flash. I've been checking current situation with flash
>>>>>>>> charts in opensource world and found this project:
>>>>>>>> http://teethgrinder.co.uk/open-flash-chart-2
>>>>>>>> I saw it before, but it used to be a charting server running on php.
>>>>>>>> Now, in version 2 they moved towards pure SWF + JSON. The charts look nice
>>>>>>>> and easy to use. It's GPL v2.
>>>>>>>>
>>>>>>>> There is another project that is worth attention:
>>>>>>>> http://developer.yahoo.com/flash/astra-flash/charts/examples.html.
>>>>>>>> It's a Yahoo SDK for flash and is not for charts only. The SDK is
>>>>>>>> under BSD. The only problem is that it's not a ready made SWF that reads
>>>>>>>> data from external file, thus it needs some flash/actionscript development
>>>>>>>> skills. However this option is more flexible because the SDK seems to
>>>>>>>> include a huge variety of primitives.
>>>>>>>>
>>>>>>>> What do you guys think?
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> -Roman
>>>>>>>>
>>>>>>>>
>>>>>>>> -------------------------------------------------------------------------
>>>>>>>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>>>>>>>> challenge
>>>>>>>> Build the coolest Linux based applications with Moblin SDK & win
>>>>>>>> great prizes
>>>>>>>> Grand prize is a trip for two to an Open Source event anywhere in
>>>>>>>> the world
>>>>>>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>>>>>>> _______________________________________________
>>>>>>>> Atalaya-developer mailing list
>>>>>>>> Atalaya-developer@...
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/atalaya-developer
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Atalaya-developer mailing list
> Atalaya-developer@...
> https://lists.sourceforge.net/lists/listinfo/atalaya-developer
>
>

--
Giacomo Collini - CISSP

Information Security Analyst

email: giacomo.collini@...
mobile: (+34)628332736

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Atalaya-developer mailing list
Atalaya-developer@...
https://lists.sourceforge.net/lists/listinfo/atalaya-developer

Re: Flash charts

2008-09-01T08:05:16Z

I took a look to commercial alternatives like FusionChart.
They are quite cheap indeed but on the other hand I would like to
stick to the "preference to open source components and libraries"
policy. So I strongly support Open Flash Charts.

Thanks,

On Mon, Sep 1, 2008 at 11:31 AM, Francesco Vivoli <f.vivoli@...> wrote:

> For me they look ok. If there is some other compelling reason for yahoo I'll
> be fine with yahoo as well.
> ciao
> F
>
> On Mon, Sep 1, 2008 at 11:19 AM, Roman Kalyakin <theorm@...> wrote:
>>
>> Okay. The last thing is to decide what charts to use. I suggest if
>> everyone is satisfied with the look'n'feel of the open flash charts, let's
>> go for it.
>>
>> -R
>>
>> On Mon, Sep 1, 2008 at 11:16 AM, Francesco Vivoli <f.vivoli@...>
>> wrote:
>>>
>>> Yes, this makes sense. After all much of the work is on the data format,
>>> which can be reused.
>>> F
>>>
>>> On Mon, Sep 1, 2008 at 11:14 AM, Roman Kalyakin <theorm@...> wrote:
>>>>
>>>> Taking into account the limitations of the bar charts, if we want to
>>>> finish the charts at once without rewriting things later, that would make
>>>> sense to implement a polar chart from the beginning. From the other side, we
>>>> could just drop in a swf bar chart instead of the polar chart and see how it
>>>> looks. If we don't like it - we write a polar chart extension.
>>>>
>>>> -R
>>>>
>>>>
>>>> On Mon, Sep 1, 2008 at 10:05 AM, Francesco Vivoli <f.vivoli@...>
>>>> wrote:
>>>>>
>>>>> Wrt to the polar chart, don't you think that changing it for a stacked
>>>>> bar chart is an option.
>>>>> We use it because we want to display multiple datasets, where each
>>>>> point represent a certain quantity.
>>>>> In the specific we are drawing a polar line (i.e, a segmented line that
>>>>> rounds the origin:)) for each asset group (sites or bu's).
>>>>> Every edge represent how much that group scored for a certain
>>>>> appliance, right?
>>>>>
>>>>> The problem with stacked bar charts is that each data point (an
>>>>> appliance for a group) is bound within [0,10], so if there are 5 appliances
>>>>> the whole bar can assume values within [0,50], with the upper value
>>>>> increasing with the number of appliances. This could lead to some
>>>>> visualization problems now that I think about it. If these SDKs provide
>>>>> zooming, which I don't know, it would be ok though.
>>>>>
>>>>> Another possibility is to have segmented bar charts (one bar per
>>>>> appliance/group, grouped by group), in this case we'd have lesser
>>>>> variability on the y's but a much wider chart.
>>>>>
>>>>> Finally, creating a polar chart in SWF would be cool. The only issue
>>>>> would be that I'd like for it to be better than JFreeChart's one, since
>>>>> right now we can't even put a label for the edges (the degrees numbers are
>>>>> hard-coded into JFree code-_-)
>>>>>
>>>>> F
>>>>>
>>>>> On Mon, Sep 1, 2008 at 9:52 AM, Roman Kalyakin <theorm@...>
>>>>> wrote:
>>>>>>
>>>>>> Hi Francesco,
>>>>>>
>>>>>> Yes. Open Flash Chart improved a lot within the last year. I checked
>>>>>> both OFC and Yahoo charts and they both don't have a polar chart. That means
>>>>>> that we have two ways: either display this data on another type of chart or
>>>>>> implement the polar chart on top of Open Flash Chart or Yahoo charts. It
>>>>>> requires however some knowledge of actionscript. I took a look at it though,
>>>>>> and it doesn't look so much different comparing to Java. So, I beleive it
>>>>>> would be not a big deal to implement it.
>>>>>>
>>>>>> Regarding the data format: Yes, JSON is more compact. And to adopt
>>>>>> Atalaya data format to the charts we can either change the format within the
>>>>>> chart or implement the xml->json converter. I think the second option is
>>>>>> better. We could even start using data in JSON format for the UI too as it
>>>>>> is more compact.
>>>>>>
>>>>>> What to choose. For me both are ok. Yahoo SDK seems more robust and
>>>>>> flexible. But it requires some coding. The fact that it's Yahoo also annoys
>>>>>> me a bit. But since it's just an SDK with primitives and not a set of charts
>>>>>> with yahoo logo on them, it's still a candidate.
>>>>>>
>>>>>> Cheers,
>>>>>> -Roman
>>>>>>
>>>>>> On Mon, Sep 1, 2008 at 9:32 AM, Francesco Vivoli <f.vivoli@...>
>>>>>> wrote:
>>>>>>>
>>>>>>> Hi Roman
>>>>>>>
>>>>>>> I had given a look at the open flash chart thang a while ago, it
>>>>>>> looked good then and it seems they have improved. As for the yahoo sdk, I
>>>>>>> don't know enough about it to make a comment.The only thing is that an year
>>>>>>> ago we decided not to use yahoo UI nor GWT, because well, there was a direct
>>>>>>> link to these bigbig corps... I don't know, maybe it's me who's too
>>>>>>> skeptical.
>>>>>>>
>>>>>>> Ok, speaking from a purely technical perspective I'd say let's look
>>>>>>> at the requirements. Right now we use time series, pie and polar charts.
>>>>>>> While the first two are supported for sure, I'm not sure about the latter.
>>>>>>>
>>>>>>> In the case we can't make polar charts well, we still can rethink how
>>>>>>> to depict the same information: a stacked bar chart could maybe do the job,
>>>>>>> couldn't it?
>>>>>>>
>>>>>>> Then there is data format issue. As you know, right now we produce
>>>>>>> XML by default which could be fed into OFC, at least before. Nevertheless I
>>>>>>> don't think it's desiderable, JSON is much more compact as a format. Beside
>>>>>>> that, the XML that produce is atalaya-domain specific, whereas we should
>>>>>>> produce an OFC-specific one. Wrt we should start investigating how to
>>>>>>> produce JSON strings from our model, i.e how to refactor the all
>>>>>>> ChartBuilder chain.
>>>>>>> What do yo guys say?
>>>>>>>
>>>>>>> ciao
>>>>>>> F
>>>>>>>
>>>>>>> On Fri, Aug 29, 2008 at 7:32 PM, Roman Kalyakin <theorm@...>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> As we discussed one of our initial goals is to move towards nice
>>>>>>>> charts, possibly flash. I've been checking current situation with flash
>>>>>>>> charts in opensource world and found this project:
>>>>>>>> http://teethgrinder.co.uk/open-flash-chart-2
>>>>>>>> I saw it before, but it used to be a charting server running on php.
>>>>>>>> Now, in version 2 they moved towards pure SWF + JSON. The charts look nice
>>>>>>>> and easy to use. It's GPL v2.
>>>>>>>>
>>>>>>>> There is another project that is worth attention:
>>>>>>>> http://developer.yahoo.com/flash/astra-flash/charts/examples.html.
>>>>>>>> It's a Yahoo SDK for flash and is not for charts only. The SDK is
>>>>>>>> under BSD. The only problem is that it's not a ready made SWF that reads
>>>>>>>> data from external file, thus it needs some flash/actionscript development
>>>>>>>> skills. However this option is more flexible because the SDK seems to
>>>>>>>> include a huge variety of primitives.
>>>>>>>>
>>>>>>>> What do you guys think?
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> -Roman
>>>>>>>>
>>>>>>>>
>>>>>>>> -------------------------------------------------------------------------
>>>>>>>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>>>>>>>> challenge
>>>>>>>> Build the coolest Linux based applications with Moblin SDK & win
>>>>>>>> great prizes
>>>>>>>> Grand prize is a trip for two to an Open Source event anywhere in
>>>>>>>> the world
>>>>>>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>>>>>>> _______________________________________________
>>>>>>>> Atalaya-developer mailing list
>>>>>>>> Atalaya-developer@...
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/atalaya-developer
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Atalaya-developer mailing list
> Atalaya-developer@...
> https://lists.sourceforge.net/lists/listinfo/atalaya-developer
>
>

Re: Flash charts

2008-09-01T02:31:44Z

For me they look ok. If there is some other compelling reason for yahoo I'll be fine with yahoo as well.
ciao
F

On Mon, Sep 1, 2008 at 11:19 AM, Roman Kalyakin <theorm@...> wrote:

Okay. The last thing is to decide what charts to use. I suggest if everyone is satisfied with the look'n'feel of the open flash charts, let's go for it.

-R

On Mon, Sep 1, 2008 at 11:16 AM, Francesco Vivoli <f.vivoli@...> wrote:

Yes, this makes sense. After all much of the work is on the data format, which can be reused.
F

On Mon, Sep 1, 2008 at 11:14 AM, Roman Kalyakin <theorm@...> wrote:

Taking into account the limitations of the bar charts, if we want to finish the charts at once without rewriting things later, that would make sense to implement a polar chart from the beginning. From the other side, we could just drop in a swf bar chart instead of the polar chart and see how it looks. If we don't like it - we write a polar chart extension.

-R

On Mon, Sep 1, 2008 at 10:05 AM, Francesco Vivoli <f.vivoli@...> wrote:

Wrt to the polar chart, don't you think that changing it for a stacked bar chart is an option.
We use it because we want to display multiple datasets, where each point represent a certain quantity.
In the specific we are drawing a polar line (i.e, a segmented line that rounds the origin:)) for each asset group (sites or bu's).
Every edge represent how much that group scored for a certain appliance, right?

The problem with stacked bar charts is that each data point (an appliance for a group) is bound within [0,10], so if there are 5 appliances the whole bar can assume values within [0,50], with the upper value increasing with the number of appliances. This could lead to some visualization problems now that I think about it. If these SDKs provide zooming, which I don't know, it would be ok though.

Another possibility is to have segmented bar charts (one bar per appliance/group, grouped by group), in this case we'd have lesser variability on the y's but a much wider chart.

Finally, creating a polar chart in SWF would be cool. The only issue would be that I'd like for it to be better than JFreeChart's one, since right now we can't even put a label for the edges (the degrees numbers are hard-coded into JFree code-_-)

F

On Mon, Sep 1, 2008 at 9:52 AM, Roman Kalyakin <theorm@...> wrote:

Hi Francesco,

Yes. Open Flash Chart improved a lot within the last year. I checked both OFC and Yahoo charts and they both don't have a polar chart. That means that we have two ways: either display this data on another type of chart or implement the polar chart on top of Open Flash Chart or Yahoo charts. It requires however some knowledge of actionscript. I took a look at it though, and it doesn't look so much different comparing to Java. So, I beleive it would be not a big deal to implement it.

Regarding the data format: Yes, JSON is more compact. And to adopt Atalaya data format to the charts we can either change the format within the chart or implement the xml->json converter. I think the second option is better. We could even start using data in JSON format for the UI too as it is more compact.

What to choose. For me both are ok. Yahoo SDK seems more robust and flexible. But it requires some coding. The fact that it's Yahoo also annoys me a bit. But since it's just an SDK with primitives and not a set of charts with yahoo logo on them, it's still a candidate.

Cheers,
-Roman

On Mon, Sep 1, 2008 at 9:32 AM, Francesco Vivoli <f.vivoli@...> wrote:

Hi Roman

I had given a look at the open flash chart thang a while ago, it looked good then and it seems they have improved. As for the yahoo sdk, I don't know enough about it to make a comment.The only thing is that an year ago we decided not to use yahoo UI nor GWT, because well, there was a direct link to these bigbig corps... I don't know, maybe it's me who's too skeptical.

Ok, speaking from a purely technical perspective I'd say let's look at the requirements. Right now we use time series, pie and polar charts. While the first two are supported for sure, I'm not sure about the latter.

In the case we can't make polar charts well, we still can rethink how to depict the same information: a stacked bar chart could maybe do the job, couldn't it?

Then there is data format issue. As you know, right now we produce XML by default which could be fed into OFC, at least before. Nevertheless I don't think it's desiderable, JSON is much more compact as a format. Beside that, the XML that produce is atalaya-domain specific, whereas we should produce an OFC-specific one. Wrt we should start investigating how to produce JSON strings from our model, i.e how to refactor the all ChartBuilder chain.
What do yo guys say?

ciao
F

On Fri, Aug 29, 2008 at 7:32 PM, Roman Kalyakin <theorm@...> wrote:

Hi,

As we discussed one of our initial goals is to move towards nice charts, possibly flash. I've been checking current situation with flash charts in opensource world and found this project:
http://teethgrinder.co.uk/open-flash-chart-2
I saw it before, but it used to be a charting server running on php. Now, in version 2 they moved towards pure SWF + JSON. The charts look nice and easy to use. It's GPL v2.

There is another project that is worth attention: http://developer.yahoo.com/flash/astra-flash/charts/examples.html.
It's a Yahoo SDK for flash and is not for charts only. The SDK is under BSD. The only problem is that it's not a ready made SWF that reads data from external file, thus it needs some flash/actionscript development skills. However this option is more flexible because the SDK seems to include a huge variety of primitives.

What do you guys think?

Cheers,
-Roman

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Atalaya-developer mailing list
Atalaya-developer@...
https://lists.sourceforge.net/lists/listinfo/atalaya-developer

Re: Flash charts

2008-09-01T02:19:24Z

Okay. The last thing is to decide what charts to use. I suggest if everyone is satisfied with the look'n'feel of the open flash charts, let's go for it.

-R

On Mon, Sep 1, 2008 at 11:16 AM, Francesco Vivoli <f.vivoli@...> wrote:

Yes, this makes sense. After all much of the work is on the data format, which can be reused.
F

On Mon, Sep 1, 2008 at 11:14 AM, Roman Kalyakin <theorm@...> wrote:

Taking into account the limitations of the bar charts, if we want to finish the charts at once without rewriting things later, that would make sense to implement a polar chart from the beginning. From the other side, we could just drop in a swf bar chart instead of the polar chart and see how it looks. If we don't like it - we write a polar chart extension.

-R

On Mon, Sep 1, 2008 at 10:05 AM, Francesco Vivoli <f.vivoli@...> wrote:

Wrt to the polar chart, don't you think that changing it for a stacked bar chart is an option.
We use it because we want to display multiple datasets, where each point represent a certain quantity.
In the specific we are drawing a polar line (i.e, a segmented line that rounds the origin:)) for each asset group (sites or bu's).
Every edge represent how much that group scored for a certain appliance, right?

The problem with stacked bar charts is that each data point (an appliance for a group) is bound within [0,10], so if there are 5 appliances the whole bar can assume values within [0,50], with the upper value increasing with the number of appliances. This could lead to some visualization problems now that I think about it. If these SDKs provide zooming, which I don't know, it would be ok though.

Another possibility is to have segmented bar charts (one bar per appliance/group, grouped by group), in this case we'd have lesser variability on the y's but a much wider chart.

Finally, creating a polar chart in SWF would be cool. The only issue would be that I'd like for it to be better than JFreeChart's one, since right now we can't even put a label for the edges (the degrees numbers are hard-coded into JFree code-_-)

F

On Mon, Sep 1, 2008 at 9:52 AM, Roman Kalyakin <theorm@...> wrote:

Hi Francesco,

Yes. Open Flash Chart improved a lot within the last year. I checked both OFC and Yahoo charts and they both don't have a polar chart. That means that we have two ways: either display this data on another type of chart or implement the polar chart on top of Open Flash Chart or Yahoo charts. It requires however some knowledge of actionscript. I took a look at it though, and it doesn't look so much different comparing to Java. So, I beleive it would be not a big deal to implement it.

Regarding the data format: Yes, JSON is more compact. And to adopt Atalaya data format to the charts we can either change the format within the chart or implement the xml->json converter. I think the second option is better. We could even start using data in JSON format for the UI too as it is more compact.

What to choose. For me both are ok. Yahoo SDK seems more robust and flexible. But it requires some coding. The fact that it's Yahoo also annoys me a bit. But since it's just an SDK with primitives and not a set of charts with yahoo logo on them, it's still a candidate.

Cheers,
-Roman

On Mon, Sep 1, 2008 at 9:32 AM, Francesco Vivoli <f.vivoli@...> wrote:

Hi Roman

I had given a look at the open flash chart thang a while ago, it looked good then and it seems they have improved. As for the yahoo sdk, I don't know enough about it to make a comment.The only thing is that an year ago we decided not to use yahoo UI nor GWT, because well, there was a direct link to these bigbig corps... I don't know, maybe it's me who's too skeptical.

Ok, speaking from a purely technical perspective I'd say let's look at the requirements. Right now we use time series, pie and polar charts. While the first two are supported for sure, I'm not sure about the latter.

In the case we can't make polar charts well, we still can rethink how to depict the same information: a stacked bar chart could maybe do the job, couldn't it?

Then there is data format issue. As you know, right now we produce XML by default which could be fed into OFC, at least before. Nevertheless I don't think it's desiderable, JSON is much more compact as a format. Beside that, the XML that produce is atalaya-domain specific, whereas we should produce an OFC-specific one. Wrt we should start investigating how to produce JSON strings from our model, i.e how to refactor the all ChartBuilder chain.
What do yo guys say?

ciao
F

On Fri, Aug 29, 2008 at 7:32 PM, Roman Kalyakin <theorm@...> wrote:

Hi,

As we discussed one of our initial goals is to move towards nice charts, possibly flash. I've been checking current situation with flash charts in opensource world and found this project:
http://teethgrinder.co.uk/open-flash-chart-2
I saw it before, but it used to be a charting server running on php. Now, in version 2 they moved towards pure SWF + JSON. The charts look nice and easy to use. It's GPL v2.

There is another project that is worth attention: http://developer.yahoo.com/flash/astra-flash/charts/examples.html.
It's a Yahoo SDK for flash and is not for charts only. The SDK is under BSD. The only problem is that it's not a ready made SWF that reads data from external file, thus it needs some flash/actionscript development skills. However this option is more flexible because the SDK seems to include a huge variety of primitives.

What do you guys think?

Cheers,
-Roman

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Atalaya-developer mailing list
Atalaya-developer@...
https://lists.sourceforge.net/lists/listinfo/atalaya-developer

Re: Flash charts

2008-09-01T02:16:14Z

Yes, this makes sense. After all much of the work is on the data format, which can be reused.
F

On Mon, Sep 1, 2008 at 11:14 AM, Roman Kalyakin <theorm@...> wrote:

Taking into account the limitations of the bar charts, if we want to finish the charts at once without rewriting things later, that would make sense to implement a polar chart from the beginning. From the other side, we could just drop in a swf bar chart instead of the polar chart and see how it looks. If we don't like it - we write a polar chart extension.

-R

On Mon, Sep 1, 2008 at 10:05 AM, Francesco Vivoli <f.vivoli@...> wrote:

Wrt to the polar chart, don't you think that changing it for a stacked bar chart is an option.
We use it because we want to display multiple datasets, where each point represent a certain quantity.
In the specific we are drawing a polar line (i.e, a segmented line that rounds the origin:)) for each asset group (sites or bu's).
Every edge represent how much that group scored for a certain appliance, right?

The problem with stacked bar charts is that each data point (an appliance for a group) is bound within [0,10], so if there are 5 appliances the whole bar can assume values within [0,50], with the upper value increasing with the number of appliances. This could lead to some visualization problems now that I think about it. If these SDKs provide zooming, which I don't know, it would be ok though.

Another possibility is to have segmented bar charts (one bar per appliance/group, grouped by group), in this case we'd have lesser variability on the y's but a much wider chart.

Finally, creating a polar chart in SWF would be cool. The only issue would be that I'd like for it to be better than JFreeChart's one, since right now we can't even put a label for the edges (the degrees numbers are hard-coded into JFree code-_-)

F

On Mon, Sep 1, 2008 at 9:52 AM, Roman Kalyakin <theorm@...> wrote:

Hi Francesco,

Yes. Open Flash Chart improved a lot within the last year. I checked both OFC and Yahoo charts and they both don't have a polar chart. That means that we have two ways: either display this data on another type of chart or implement the polar chart on top of Open Flash Chart or Yahoo charts. It requires however some knowledge of actionscript. I took a look at it though, and it doesn't look so much different comparing to Java. So, I beleive it would be not a big deal to implement it.

Regarding the data format: Yes, JSON is more compact. And to adopt Atalaya data format to the charts we can either change the format within the chart or implement the xml->json converter. I think the second option is better. We could even start using data in JSON format for the UI too as it is more compact.

What to choose. For me both are ok. Yahoo SDK seems more robust and flexible. But it requires some coding. The fact that it's Yahoo also annoys me a bit. But since it's just an SDK with primitives and not a set of charts with yahoo logo on them, it's still a candidate.

Cheers,
-Roman

On Mon, Sep 1, 2008 at 9:32 AM, Francesco Vivoli <f.vivoli@...> wrote:

Hi Roman

I had given a look at the open flash chart thang a while ago, it looked good then and it seems they have improved. As for the yahoo sdk, I don't know enough about it to make a comment.The only thing is that an year ago we decided not to use yahoo UI nor GWT, because well, there was a direct link to these bigbig corps... I don't know, maybe it's me who's too skeptical.

Ok, speaking from a purely technical perspective I'd say let's look at the requirements. Right now we use time series, pie and polar charts. While the first two are supported for sure, I'm not sure about the latter.

In the case we can't make polar charts well, we still can rethink how to depict the same information: a stacked bar chart could maybe do the job, couldn't it?

Then there is data format issue. As you know, right now we produce XML by default which could be fed into OFC, at least before. Nevertheless I don't think it's desiderable, JSON is much more compact as a format. Beside that, the XML that produce is atalaya-domain specific, whereas we should produce an OFC-specific one. Wrt we should start investigating how to produce JSON strings from our model, i.e how to refactor the all ChartBuilder chain.
What do yo guys say?

ciao
F

On Fri, Aug 29, 2008 at 7:32 PM, Roman Kalyakin <theorm@...> wrote:

Hi,

As we discussed one of our initial goals is to move towards nice charts, possibly flash. I've been checking current situation with flash charts in opensource world and found this project:
http://teethgrinder.co.uk/open-flash-chart-2
I saw it before, but it used to be a charting server running on php. Now, in version 2 they moved towards pure SWF + JSON. The charts look nice and easy to use. It's GPL v2.

There is another project that is worth attention: http://developer.yahoo.com/flash/astra-flash/charts/examples.html.
It's a Yahoo SDK for flash and is not for charts only. The SDK is under BSD. The only problem is that it's not a ready made SWF that reads data from external file, thus it needs some flash/actionscript development skills. However this option is more flexible because the SDK seems to include a huge variety of primitives.

What do you guys think?

Cheers,
-Roman

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Atalaya-developer mailing list
Atalaya-developer@...
https://lists.sourceforge.net/lists/listinfo/atalaya-developer

Re: Flash charts

2008-09-01T02:14:25Z

Taking into account the limitations of the bar charts, if we want to finish the charts at once without rewriting things later, that would make sense to implement a polar chart from the beginning. From the other side, we could just drop in a swf bar chart instead of the polar chart and see how it looks. If we don't like it - we write a polar chart extension.

-R

On Mon, Sep 1, 2008 at 10:05 AM, Francesco Vivoli <f.vivoli@...> wrote:

Wrt to the polar chart, don't you think that changing it for a stacked bar chart is an option.
We use it because we want to display multiple datasets, where each point represent a certain quantity.
In the specific we are drawing a polar line (i.e, a segmented line that rounds the origin:)) for each asset group (sites or bu's).
Every edge represent how much that group scored for a certain appliance, right?

The problem with stacked bar charts is that each data point (an appliance for a group) is bound within [0,10], so if there are 5 appliances the whole bar can assume values within [0,50], with the upper value increasing with the number of appliances. This could lead to some visualization problems now that I think about it. If these SDKs provide zooming, which I don't know, it would be ok though.

Another possibility is to have segmented bar charts (one bar per appliance/group, grouped by group), in this case we'd have lesser variability on the y's but a much wider chart.

Finally, creating a polar chart in SWF would be cool. The only issue would be that I'd like for it to be better than JFreeChart's one, since right now we can't even put a label for the edges (the degrees numbers are hard-coded into JFree code-_-)

F

On Mon, Sep 1, 2008 at 9:52 AM, Roman Kalyakin <theorm@...> wrote:

Hi Francesco,

Yes. Open Flash Chart improved a lot within the last year. I checked both OFC and Yahoo charts and they both don't have a polar chart. That means that we have two ways: either display this data on another type of chart or implement the polar chart on top of Open Flash Chart or Yahoo charts. It requires however some knowledge of actionscript. I took a look at it though, and it doesn't look so much different comparing to Java. So, I beleive it would be not a big deal to implement it.

Regarding the data format: Yes, JSON is more compact. And to adopt Atalaya data format to the charts we can either change the format within the chart or implement the xml->json converter. I think the second option is better. We could even start using data in JSON format for the UI too as it is more compact.

What to choose. For me both are ok. Yahoo SDK seems more robust and flexible. But it requires some coding. The fact that it's Yahoo also annoys me a bit. But since it's just an SDK with primitives and not a set of charts with yahoo logo on them, it's still a candidate.

Cheers,
-Roman

On Mon, Sep 1, 2008 at 9:32 AM, Francesco Vivoli <f.vivoli@...> wrote:

Hi Roman

I had given a look at the open flash chart thang a while ago, it looked good then and it seems they have improved. As for the yahoo sdk, I don't know enough about it to make a comment.The only thing is that an year ago we decided not to use yahoo UI nor GWT, because well, there was a direct link to these bigbig corps... I don't know, maybe it's me who's too skeptical.

Ok, speaking from a purely technical perspective I'd say let's look at the requirements. Right now we use time series, pie and polar charts. While the first two are supported for sure, I'm not sure about the latter.

In the case we can't make polar charts well, we still can rethink how to depict the same information: a stacked bar chart could maybe do the job, couldn't it?

Then there is data format issue. As you know, right now we produce XML by default which could be fed into OFC, at least before. Nevertheless I don't think it's desiderable, JSON is much more compact as a format. Beside that, the XML that produce is atalaya-domain specific, whereas we should produce an OFC-specific one. Wrt we should start investigating how to produce JSON strings from our model, i.e how to refactor the all ChartBuilder chain.
What do yo guys say?

ciao
F

On Fri, Aug 29, 2008 at 7:32 PM, Roman Kalyakin <theorm@...> wrote:

Hi,

As we discussed one of our initial goals is to move towards nice charts, possibly flash. I've been checking current situation with flash charts in opensource world and found this project:
http://teethgrinder.co.uk/open-flash-chart-2
I saw it before, but it used to be a charting server running on php. Now, in version 2 they moved towards pure SWF + JSON. The charts look nice and easy to use. It's GPL v2.

There is another project that is worth attention: http://developer.yahoo.com/flash/astra-flash/charts/examples.html.
It's a Yahoo SDK for flash and is not for charts only. The SDK is under BSD. The only problem is that it's not a ready made SWF that reads data from external file, thus it needs some flash/actionscript development skills. However this option is more flexible because the SDK seems to include a huge variety of primitives.

What do you guys think?

Cheers,
-Roman

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Atalaya-developer mailing list
Atalaya-developer@...
https://lists.sourceforge.net/lists/listinfo/atalaya-developer

Re: Flash charts

2008-09-01T01:05:27Z

Wrt to the polar chart, don't you think that changing it for a stacked bar chart is an option.
We use it because we want to display multiple datasets, where each point represent a certain quantity.
In the specific we are drawing a polar line (i.e, a segmented line that rounds the origin:)) for each asset group (sites or bu's).
Every edge represent how much that group scored for a certain appliance, right?

The problem with stacked bar charts is that each data point (an appliance for a group) is bound within [0,10], so if there are 5 appliances the whole bar can assume values within [0,50], with the upper value increasing with the number of appliances. This could lead to some visualization problems now that I think about it. If these SDKs provide zooming, which I don't know, it would be ok though.

Another possibility is to have segmented bar charts (one bar per appliance/group, grouped by group), in this case we'd have lesser variability on the y's but a much wider chart.

Finally, creating a polar chart in SWF would be cool. The only issue would be that I'd like for it to be better than JFreeChart's one, since right now we can't even put a label for the edges (the degrees numbers are hard-coded into JFree code-_-)

F

On Mon, Sep 1, 2008 at 9:52 AM, Roman Kalyakin <theorm@...> wrote:

Hi Francesco,

Yes. Open Flash Chart improved a lot within the last year. I checked both OFC and Yahoo charts and they both don't have a polar chart. That means that we have two ways: either display this data on another type of chart or implement the polar chart on top of Open Flash Chart or Yahoo charts. It requires however some knowledge of actionscript. I took a look at it though, and it doesn't look so much different comparing to Java. So, I beleive it would be not a big deal to implement it.

Regarding the data format: Yes, JSON is more compact. And to adopt Atalaya data format to the charts we can either change the format within the chart or implement the xml->json converter. I think the second option is better. We could even start using data in JSON format for the UI too as it is more compact.

What to choose. For me both are ok. Yahoo SDK seems more robust and flexible. But it requires some coding. The fact that it's Yahoo also annoys me a bit. But since it's just an SDK with primitives and not a set of charts with yahoo logo on them, it's still a candidate.

Cheers,
-Roman

On Mon, Sep 1, 2008 at 9:32 AM, Francesco Vivoli <f.vivoli@...> wrote:

Hi Roman

I had given a look at the open flash chart thang a while ago, it looked good then and it seems they have improved. As for the yahoo sdk, I don't know enough about it to make a comment.The only thing is that an year ago we decided not to use yahoo UI nor GWT, because well, there was a direct link to these bigbig corps... I don't know, maybe it's me who's too skeptical.

Ok, speaking from a purely technical perspective I'd say let's look at the requirements. Right now we use time series, pie and polar charts. While the first two are supported for sure, I'm not sure about the latter.

In the case we can't make polar charts well, we still can rethink how to depict the same information: a stacked bar chart could maybe do the job, couldn't it?

Then there is data format issue. As you know, right now we produce XML by default which could be fed into OFC, at least before. Nevertheless I don't think it's desiderable, JSON is much more compact as a format. Beside that, the XML that produce is atalaya-domain specific, whereas we should produce an OFC-specific one. Wrt we should start investigating how to produce JSON strings from our model, i.e how to refactor the all ChartBuilder chain.
What do yo guys say?

ciao
F

On Fri, Aug 29, 2008 at 7:32 PM, Roman Kalyakin <theorm@...> wrote:

Hi,

As we discussed one of our initial goals is to move towards nice charts, possibly flash. I've been checking current situation with flash charts in opensource world and found this project:
http://teethgrinder.co.uk/open-flash-chart-2
I saw it before, but it used to be a charting server running on php. Now, in version 2 they moved towards pure SWF + JSON. The charts look nice and easy to use. It's GPL v2.

There is another project that is worth attention: http://developer.yahoo.com/flash/astra-flash/charts/examples.html.
It's a Yahoo SDK for flash and is not for charts only. The SDK is under BSD. The only problem is that it's not a ready made SWF that reads data from external file, thus it needs some flash/actionscript development skills. However this option is more flexible because the SDK seems to include a huge variety of primitives.

What do you guys think?

Cheers,
-Roman

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Atalaya-developer mailing list
Atalaya-developer@...
https://lists.sourceforge.net/lists/listinfo/atalaya-developer

Re: Flash charts

2008-09-01T00:52:49Z

Hi Francesco,

Yes. Open Flash Chart improved a lot within the last year. I checked both OFC and Yahoo charts and they both don't have a polar chart. That means that we have two ways: either display this data on another type of chart or implement the polar chart on top of Open Flash Chart or Yahoo charts. It requires however some knowledge of actionscript. I took a look at it though, and it doesn't look so much different comparing to Java. So, I beleive it would be not a big deal to implement it.

Regarding the data format: Yes, JSON is more compact. And to adopt Atalaya data format to the charts we can either change the format within the chart or implement the xml->json converter. I think the second option is better. We could even start using data in JSON format for the UI too as it is more compact.

What to choose. For me both are ok. Yahoo SDK seems more robust and flexible. But it requires some coding. The fact that it's Yahoo also annoys me a bit. But since it's just an SDK with primitives and not a set of charts with yahoo logo on them, it's still a candidate.

Cheers,
-Roman

On Mon, Sep 1, 2008 at 9:32 AM, Francesco Vivoli <f.vivoli@...> wrote:

Hi Roman

I had given a look at the open flash chart thang a while ago, it looked good then and it seems they have improved. As for the yahoo sdk, I don't know enough about it to make a comment.The only thing is that an year ago we decided not to use yahoo UI nor GWT, because well, there was a direct link to these bigbig corps... I don't know, maybe it's me who's too skeptical.

Ok, speaking from a purely technical perspective I'd say let's look at the requirements. Right now we use time series, pie and polar charts. While the first two are supported for sure, I'm not sure about the latter.

In the case we can't make polar charts well, we still can rethink how to depict the same information: a stacked bar chart could maybe do the job, couldn't it?

Then there is data format issue. As you know, right now we produce XML by default which could be fed into OFC, at least before. Nevertheless I don't think it's desiderable, JSON is much more compact as a format. Beside that, the XML that produce is atalaya-domain specific, whereas we should produce an OFC-specific one. Wrt we should start investigating how to produce JSON strings from our model, i.e how to refactor the all ChartBuilder chain.
What do yo guys say?

ciao
F

On Fri, Aug 29, 2008 at 7:32 PM, Roman Kalyakin <theorm@...> wrote:

Hi,

As we discussed one of our initial goals is to move towards nice charts, possibly flash. I've been checking current situation with flash charts in opensource world and found this project:
http://teethgrinder.co.uk/open-flash-chart-2
I saw it before, but it used to be a charting server running on php. Now, in version 2 they moved towards pure SWF + JSON. The charts look nice and easy to use. It's GPL v2.

There is another project that is worth attention: http://developer.yahoo.com/flash/astra-flash/charts/examples.html.
It's a Yahoo SDK for flash and is not for charts only. The SDK is under BSD. The only problem is that it's not a ready made SWF that reads data from external file, thus it needs some flash/actionscript development skills. However this option is more flexible because the SDK seems to include a huge variety of primitives.

What do you guys think?

Cheers,
-Roman

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Atalaya-developer mailing list
Atalaya-developer@...
https://lists.sourceforge.net/lists/listinfo/atalaya-developer

Re: Flash charts

2008-09-01T00:32:52Z

Hi Roman

I had given a look at the open flash chart thang a while ago, it looked good then and it seems they have improved. As for the yahoo sdk, I don't know enough about it to make a comment.The only thing is that an year ago we decided not to use yahoo UI nor GWT, because well, there was a direct link to these bigbig corps... I don't know, maybe it's me who's too skeptical.

Ok, speaking from a purely technical perspective I'd say let's look at the requirements. Right now we use time series, pie and polar charts. While the first two are supported for sure, I'm not sure about the latter.

In the case we can't make polar charts well, we still can rethink how to depict the same information: a stacked bar chart could maybe do the job, couldn't it?

Then there is data format issue. As you know, right now we produce XML by default which could be fed into OFC, at least before. Nevertheless I don't think it's desiderable, JSON is much more compact as a format. Beside that, the XML that produce is atalaya-domain specific, whereas we should produce an OFC-specific one. Wrt we should start investigating how to produce JSON strings from our model, i.e how to refactor the all ChartBuilder chain.
What do yo guys say?

ciao
F

On Fri, Aug 29, 2008 at 7:32 PM, Roman Kalyakin <theorm@...> wrote:

Hi,

As we discussed one of our initial goals is to move towards nice charts, possibly flash. I've been checking current situation with flash charts in opensource world and found this project:
http://teethgrinder.co.uk/open-flash-chart-2
I saw it before, but it used to be a charting server running on php. Now, in version 2 they moved towards pure SWF + JSON. The charts look nice and easy to use. It's GPL v2.

There is another project that is worth attention: http://developer.yahoo.com/flash/astra-flash/charts/examples.html.
It's a Yahoo SDK for flash and is not for charts only. The SDK is under BSD. The only problem is that it's not a ready made SWF that reads data from external file, thus it needs some flash/actionscript development skills. However this option is more flexible because the SDK seems to include a huge variety of primitives.

What do you guys think?

Cheers,
-Roman

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Atalaya-developer mailing list
Atalaya-developer@...
https://lists.sourceforge.net/lists/listinfo/atalaya-developer

Flash charts

2008-08-29T10:32:15Z

Hi,

As we discussed one of our initial goals is to move towards nice charts, possibly flash. I've been checking current situation with flash charts in opensource world and found this project:
http://teethgrinder.co.uk/open-flash-chart-2
I saw it before, but it used to be a charting server running on php. Now, in version 2 they moved towards pure SWF + JSON. The charts look nice and easy to use. It's GPL v2.

There is another project that is worth attention: http://developer.yahoo.com/flash/astra-flash/charts/examples.html.
It's a Yahoo SDK for flash and is not for charts only. The SDK is under BSD. The only problem is that it's not a ready made SWF that reads data from external file, thus it needs some flash/actionscript development skills. However this option is more flexible because the SDK seems to include a huge variety of primitives.

What do you guys think?

Cheers,
-Roman

bug tracking

2008-08-29T08:23:52Z

Hello,

I cleaned up the bugs list in order to start working seriously on them.
Almost all of them are UI bugs; they should be fixed asap.
I took a deep look to the UI on the demo and I found only few bugs but
a lot of missing nice-to-have. As a common policy we should avoid
talking about these before we are satisfied with the current
configuration :)

Thanks,

--
Giacomo Collini - CISSP

Information Security Analyst

email: giacomo.collini@...
mobile: (+34)628332736

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Atalaya-developer mailing list
Atalaya-developer@...
https://lists.sourceforge.net/lists/listinfo/atalaya-developer

Re: New ticketing system?

2008-08-29T02:43:27Z

On Thu, Aug 28, 2008 at 11:52 AM, Roman Kalyakin <theorm@...> wrote:
> cut
> Conclusion: I would give launchpad a try. It's robust and doesn't seem to
> disappear within the following two years. If not, then Jira is a better
> option than Trac. They both do not have a hosted option, and the rest of
> pros and cons speak for Jira.
>

Hi guys,

As I don't have a considerable experience on these platforms I don't
have a strong opinion. For sure the effort of migrating to a new
platform is compensate by the cumbersomeness of SF ticketing system.

I will support any decision the team will take.

Thanks

--
Giacomo Collini - CISSP

Information Security Analyst

email: giacomo.collini@...
mobile: (+34)628332736

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Atalaya-developer mailing list
Atalaya-developer@...
https://lists.sourceforge.net/lists/listinfo/atalaya-developer

Re: New ticketing system?

2008-08-28T02:52:03Z

Hi,

Francesco, you were faster than me with the post. :)

I more or less agree with everything Francesco wrote. To avoid duplications I'll just summarize pros and cons for each one of the ticketing systems:

Jira:
+ Well known in Java community and robust.
+ Has nice interface and useful features.
+ We have experience with it (at least me and Francesco)
- It's not hosted. There are hosting options, but they are not for free.
- Personally, the process of requesting an OS license somehow distracts me.

Trac:
+ Opensource and free. Anyone can contribute and request new features.
- We do not have experience with it.
- Not so user friendly interface.
- Not hosted. There are some options, but they are semi-free and don't look reliable and mostly have restrictions for completely free accounts.

Launchpad:
+ Opensource and free.
+ Hosted, a good competitor of sourceforge but looks more advanced.
+ User friendly. Compares to sourceforge like web 1.0 to web 2.0
-+ As Francesco mentioned, it's tightly coupled with Bazaar. However, there is an option of syncing remote repository with bazaar automatically.
- I'm not sure about a variety of features, but many features also make it difficult to maintain the project.

Conclusion: I would give launchpad a try. It's robust and doesn't seem to disappear within the following two years. If not, then Jira is a better option than Trac. They both do not have a hosted option, and the rest of pros and cons speak for Jira.

Cheers,
Roman

On Wed, Aug 27, 2008 at 11:40 PM, Francesco Vivoli <f.vivoli@...> wrote:

Hoi

feeling inspired I've written a blog entry with some random thoughts.
http://blogs.atalayasec.org/dev/2008/08/choosing-the-right-ticketing-system-jira-vs-trac-vs-launchpad/

Roman, I'd like to hear your opinion about what we should go for. Launchpad is appealing to me but it means a bigger migration (especially away from SVN:S)
cheers
F

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Atalaya-developer mailing list
Atalaya-developer@...
https://lists.sourceforge.net/lists/listinfo/atalaya-developer

New ticketing system?

2008-08-27T14:40:52Z

Hoi

feeling inspired I've written a blog entry with some random thoughts.
http://blogs.atalayasec.org/dev/2008/08/choosing-the-right-ticketing-system-jira-vs-trac-vs-launchpad/

Roman, I'd like to hear your opinion about what we should go for. Launchpad is appealing to me but it means a bigger migration (especially away from SVN:S)
cheers
F

Re: 1st Atalaya meeting minutes

2008-08-02T11:38:20Z

Hi Robert

always a pleasure to meet new people:)

wow, what you say it's actually good news, one of the main reasons for us to rethink reporting was that our current implementation sucks...

It would be real cool to draft new specs with someone with a better understanding of Jasper. Beside that, we were speculating about moving to Eclipse BIRT, would you have any opinion about such a move. One of the problems with Jasper that Giacomo had was the difficulty of producing good looking reports when datasets have an high degree of variability from one invocation to another (short/long text areas and the like...).

I'm also going on vacations next week so I'll be mostly offline, but it'd be cool to retake this topic at the end of the month.

Thanks a lot for your inputs and willingness, talk to you soon.
cheers
Francesco

On Fri, Aug 1, 2008 at 11:18 PM, Robert Kielty <r_kielty@...> wrote:

Hi,

I have spent the last three months working with JasperReports and iReports.

I have worked on designining reports, and have implemented a web app that runs reports asynchronously; (user requests a report via web app, servlet launches report fill asynchronously, a listener is notified when the report has been filled and the listener then exports the report to a file (PDF OpenOffice HTML whatever) and sets the report status as having been complete. Then the next time the web page is reload/refreshed or revisited the presence of the exported report is not and a link is displayed to a download servlet. I've glossed over one or two of the details but that's the guts of it.

I am away on vacation for the next two weeks with limited access to email but if you can roughly spec out some requirements and issues that you are face with reporting I could probably provide some input.

Kind regards,
Robert

Date: Fri, 1 Aug 2008 19:48:02 +0200
From: f.vivoli@...
To: atalaya-developer@...
CC: pablocelada@...
Subject: [Atalaya-developer] 1st Atalaya meeting minutes

Hi everybody

as promised here go the minutes of what we said between on tinto and the other:)
(and btw, I think there should be shifts for whom does the note keeping)

List of high level features (+'s for priorities)

1- reporting(-): agreed to remove the current impl and to rethink the whole thing.

2- UI(++):
   - make it smoother (cut rough edges, clutchy actions and the like)
   - fix bugs
   - improve charts (flash?)

3-plugins(+):
   - how to develop, i.e the API and also providing some basic declarative configuration mean
     (many plugins only differ for a regex...)
   - lifecycle: how to configure/deconfigure and load/unload them

4- error handling and reporting(++): be more descrptive when some updates fail

5- configuration management(+):
   - initial setup (user side)
   - for developers (what they need to import to develop plugins - see the API stuff)
   - for the project (setup TRAC and migrate from SF bug tracker)

6-issues repository(++): this means re-activating corration between security elements)

7-policies(++): finish this first impl across the appliance set

8-false positives(++): finish this first impl across the appliance set

9-XML API(+) : draft design

10-MSBA(++): implement

11-testing(): evaluate what makes sense to be tested with Selenium

Now, speaking of assignments, I think that Giacomo can easily carry on what he was doing, that is
7,8 and 10. Then I can get on 4, 6 and part of 2. Roman, as you see you've got plenty of speculative
work ahead (:)) but IMO 2.3 and 5.3 should be given priority. Then the rest of 5 would be great to
have, since it also eases our daily work. Once these things are done I'm eager to see how we
can tackle the plugin matter:)

well, friday - 19:47...I think this's enough, I'm offff!
ciao
F

It's time to join the family - Get the next generation of Free Windows Live Services now! Click here!

Re: 1st Atalaya meeting minutes

2008-08-01T14:18:42Z

Hi,

I have spent the last three months working with JasperReports and iReports.

I have worked on designining reports, and have implemented a web app that runs reports asynchronously; (user requests a report via web app, servlet launches report fill asynchronously, a listener is notified when the report has been filled and the listener then exports the report to a file (PDF OpenOffice HTML whatever) and sets the report status as having been complete. Then the next time the web page is reload/refreshed or revisited the presence of the exported report is not and a link is displayed to a download servlet. I've glossed over one or two of the details but that's the guts of it.

I am away on vacation for the next two weeks with limited access to email but if you can roughly spec out some requirements and issues that you are face with reporting I could probably provide some input.

Kind regards,
Robert

Date: Fri, 1 Aug 2008 19:48:02 +0200
From: f.vivoli@...
To: atalaya-developer@...
CC: pablocelada@...
Subject: [Atalaya-developer] 1st Atalaya meeting minutes

Hi everybody

as promised here go the minutes of what we said between on tinto and the other:)
(and btw, I think there should be shifts for whom does the note keeping)

List of high level features (+'s for priorities)

1- reporting(-): agreed to remove the current impl and to rethink the whole thing.

2- UI(++):
   - make it smoother (cut rough edges, clutchy actions and the like)
   - fix bugs
   - improve charts (flash?)

3-plugins(+):
   - how to develop, i.e the API and also providing some basic declarative configuration mean
     (many plugins only differ for a regex...)
   - lifecycle: how to configure/deconfigure and load/unload them

4- error handling and reporting(++): be more descrptive when some updates fail

5- configuration management(+):
   - initial setup (user side)
   - for developers (what they need to import to develop plugins - see the API stuff)
   - for the project (setup TRAC and migrate from SF bug tracker)

6-issues repository(++): this means re-activating corration between security elements)

7-policies(++): finish this first impl across the appliance set

8-false positives(++): finish this first impl across the appliance set

9-XML API(+) : draft design

10-MSBA(++): implement

11-testing(): evaluate what makes sense to be tested with Selenium

Now, speaking of assignments, I think that Giacomo can easily carry on what he was doing, that is
7,8 and 10. Then I can get on 4, 6 and part of 2. Roman, as you see you've got plenty of speculative
work ahead (:)) but IMO 2.3 and 5.3 should be given priority. Then the rest of 5 would be great to
have, since it also eases our daily work. Once these things are done I'm eager to see how we
can tackle the plugin matter:)

well, friday - 19:47...I think this's enough, I'm offff!
ciao
F

It’s time to join the family - Get the next generation of Free Windows Live Services now! Click here!
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Atalaya-developer mailing list
Atalaya-developer@...
https://lists.sourceforge.net/lists/listinfo/atalaya-developer

1st Atalaya meeting minutes

2008-08-01T10:48:02Z

1- reporting(-): agreed to remove the current impl and to rethink the whole thing.