You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openmeetings.apache.org by Maxim Solodovnik <so...@gmail.com> on 2016/08/01 14:21:12 UTC
Re: AppointmentManager Client State clarification
If I were you I would create final field for the client (if it is
serializable)
On Fri, Jul 22, 2016 at 8:08 PM, Ankush Mishra <an...@gmail.com>
wrote:
> Hey Maxim, Sebastian,
>
> Just a small thing, should I keep the HTTPClient object in the memory for
> the whole page until say, the CalendarPanel is removed or should I just
> have the client for the period of the syncing?
>
> Keeping the Client until would store the credentials in the memory for
> that period. So, the initial sync would require the user to enter the
> credentials, but for the subsequent syncs, the credentials don't need to be
> entered. But, if we don't then the credentials would be required to be
> entered multiple times while the Panel is open, but the credentials would
> not reside in the memory.
>
>
> --
> Ankush Mishra
>
>
--
WBR
Maxim aka solomax
Re: AppointmentManager Client State clarification
Posted by Maxim Solodovnik <so...@gmail.com>.
Let's start with PR, I can perform code review on it then we will convert
to the patch file and will attach to the JIRA item
According to the documentation:
-- javadocs are required
-- in case any additional configuration is required it worth to create
page in /openmeetings-parent/openmeetings-server/src/site/xdoc with
required steps, comments etc
On Tue, Aug 9, 2016 at 11:35 PM, Ankush Mishra <an...@gmail.com>
wrote:
> Hey Maxim,
>
> Currently my repository is pretty much up to date on the OM sources.
>
> Should I make a Pull Request or a Patch? Either way is fine with me. Just
> let me know where I have to do what in this regard.
>
> With regard to the Code Reviews, I'll be doing them this week. Also, feel
> free to test my respository, here: https://github.com/
> TheAntimist/openmeetings/tree/3.2.x , if you do require a CalDAV server
> to test it on, just let me know, I have a couple of temporary accounts
> which can be used for testing.
>
> Also, Submission guidelines are here: https://developers.google.com/
> open-source/gsoc/help/work-product.
>
> A couple of things, I want to ask is, first, there's a mention of :
>
> There's documentation of what and why.
>
> Should I add anything specific? Other than Javadoc comments and so on,
> which are already present.
>
> Also, for the Submission should I just link to all my commits on my
> Openmeetings Repository, along with that should I also mention the caldav4j
> modifications as well? Or should we do something else like link to the Bug
> Tracker?
>
> Much Thanks
>
> Ankush Mishra
> On 08/08/2016 11:08 AM, Maxim Solodovnik wrote:
>
> In case everything done, I would prefer you to prepare "official" patch to
> OM
>
> GSOC rules for final evaluation were changed, so I prefer to get
> everything prepared, then move forward
>
> this should include:
> 1) merge latest OM sources to your branch
> 2) prepare patch/PR
> 3) complete couple of code reviews
> 4) attach patch to JIRA issue
>
> both of as need to walk through code submit rules to ensure me don't miss
> anything
>
> @Sebastian could you please also check this guide?
>
> --
> WBR
> Maxim aka solomax
>
>
> --
> Ankush Mishra
>
>
--
WBR
Maxim aka solomax
Re: AppointmentManager Client State clarification
Posted by Ankush Mishra <an...@gmail.com>.
Hey Maxim,
Currently my repository is pretty much up to date on the OM sources.
Should I make a Pull Request or a Patch? Either way is fine with me.
Just let me know where I have to do what in this regard.
With regard to the Code Reviews, I'll be doing them this week. Also,
feel free to test my respository, here:
https://github.com/TheAntimist/openmeetings/tree/3.2.x , if you do
require a CalDAV server to test it on, just let me know, I have a couple
of temporary accounts which can be used for testing.
Also, Submission guidelines are here:
https://developers.google.com/open-source/gsoc/help/work-product.
A couple of things, I want to ask is, first, there's a mention of :
There's documentation of what and why.
Should I add anything specific? Other than Javadoc comments and so on,
which are already present.
Also, for the Submission should I just link to all my commits on my
Openmeetings Repository, along with that should I also mention the
caldav4j modifications as well? Or should we do something else like link
to the Bug Tracker?
Much Thanks
Ankush Mishra
On 08/08/2016 11:08 AM, Maxim Solodovnik wrote:
> In case everything done, I would prefer you to prepare "official"
> patch to OM
>
> GSOC rules for final evaluation were changed, so I prefer to get
> everything prepared, then move forward
>
> this should include:
> 1) merge latest OM sources to your branch
> 2) prepare patch/PR
> 3) complete couple of code reviews
> 4) attach patch to JIRA issue
>
> both of as need to walk through code submit rules to ensure me don't
> miss anything
>
> @Sebastian could you please also check this guide?
>
> --
> WBR
> Maxim aka solomax
--
Ankush Mishra
Re: AppointmentManager Client State clarification
Posted by Maxim Solodovnik <so...@gmail.com>.
In case everything done, I would prefer you to prepare "official" patch to
OM
GSOC rules for final evaluation were changed, so I prefer to get everything
prepared, then move forward
this should include:
1) merge latest OM sources to your branch
2) prepare patch/PR
3) complete couple of code reviews
4) attach patch to JIRA issue
both of as need to walk through code submit rules to ensure me don't miss
anything
@Sebastian could you please also check this guide?
On Thu, Aug 4, 2016 at 6:01 PM, Ankush Mishra <an...@gmail.com>
wrote:
> not sure what are you talking about :(
>
> Well, first off my objectives on the CalDAV client is mostly complete.
> I've been mostly testing making small improvements here and there.
>
> But otherwise it should be complete, as such, I was wondering if you'd
> like me to implement anything else. I am mostly thinking of implementing
> the import of iCalendar files. This is already sort of implemented, I'll
> probably have to extend a function for importing multiple VEVENT's at a
> time. Users should be able to add iCalendar files using the same button
> where we add the calendar for CalDAV as well. Should I implement it?
>
> This also, brings up, that if I am going to implement the importing, I
> could also implement the exporting as well. Just that not sure where I'd
> add a setting on the wicket page for it. I'll probably add a function to
> export, for now.
>
>
> Ankush Mishra
>
--
WBR
Maxim aka solomax
Re: AppointmentManager Client State clarification
Posted by Ankush Mishra <an...@gmail.com>.
> not sure what are you talking about :(
Well, first off my objectives on the CalDAV client is mostly complete.
I've been mostly testing making small improvements here and there.
But otherwise it should be complete, as such, I was wondering if you'd
like me to implement anything else. I am mostly thinking of implementing
the import of iCalendar files. This is already sort of implemented, I'll
probably have to extend a function for importing multiple VEVENT's at a
time. Users should be able to add iCalendar files using the same button
where we add the calendar for CalDAV as well. Should I implement it?
This also, brings up, that if I am going to implement the importing, I
could also implement the exporting as well. Just that not sure where I'd
add a setting on the wicket page for it. I'll probably add a function to
export, for now.
Ankush Mishra
Re: AppointmentManager Client State clarification
Posted by Maxim Solodovnik <so...@gmail.com>.
>> should I add any additional functionality to the CalDAV Client or
anything really related to my project.
not sure what are you talking about :(
On Wed, Aug 3, 2016 at 10:26 PM, Ankush Mishra <an...@gmail.com>
wrote:
> Alright, this clears up a couple of things. Also, should I add any
> additional functionality to the CalDAV Client or anything really related to
> my project.
>
> Ankush Mishra
>
> On 08/03/2016 12:26 PM, Maxim Solodovnik wrote:
>
> It this case let it be AS IS, do not have credentials in memory.
>
> We can rely on snapshot or put "fake" version to our repo, not a big issue
>
> --
> WBR
> Maxim aka solomax
>
>
> --
> Ankush Mishra
>
>
--
WBR
Maxim aka solomax
Re: AppointmentManager Client State clarification
Posted by Ankush Mishra <an...@gmail.com>.
Alright, this clears up a couple of things. Also, should I add any
additional functionality to the CalDAV Client or anything really related
to my project.
Ankush Mishra
On 08/03/2016 12:26 PM, Maxim Solodovnik wrote:
> It this case let it be AS IS, do not have credentials in memory.
>
> We can rely on snapshot or put "fake" version to our repo, not a big issue
>
> --
> WBR
> Maxim aka solomax
--
Ankush Mishra
Re: AppointmentManager Client State clarification
Posted by Maxim Solodovnik <so...@gmail.com>.
It this case let it be AS IS, do not have credentials in memory.
We can rely on snapshot or put "fake" version to our repo, not a big issue
On Wed, Aug 3, 2016 at 3:01 AM, Ankush Mishra <an...@gmail.com>
wrote:
> Thanks for the reply but I am not sure if I follow with what you are
> saying. As HttpClient is not serializable atleast not the
> commons-httpclient, I am not sure what good it would help. Currently in my
> AppointmentManager
> <https://github.com/TheAntimist/openmeetings/blob/3.2.x/openmeetings-service/src/main/java/org/apache/openmeetings/service/calendar/caldav/AppointmentManager.java>,
> I have ensured the creation of only one HttpClient and reusing the old one,
> if one already exists. [Code]
> <https://github.com/TheAntimist/openmeetings/blob/3.2.x/openmeetings-service/src/main/java/org/apache/openmeetings/service/calendar/caldav/AppointmentManager.java#L75>
> But currently the behaviour for the user and password prompts are whenever
> the server returns a 401 Unauthorized, but I don't keep the credentials in
> the memory only for the period of that sync. And then remove them. This
> causes the user to enter the credentials for each sync.
>
> So, I was wondering if I should keep the credentials in memory for the
> period of when the CalendarPanel is visible before replace. But it's just a
> suggestion, because implementing this, would require me to keep a
> Credential or StateTable, for each user in the CalendarPanel, so as to
> seperate the data of the each user for different hosts. Personally, I could
> implement it, but not sure if it's necessary.
>
> Also, as I stated earlier about caldav4j, the library I modified to use,
> currently most of my modifications have been included into the developer
> branch here: https://github.com/caldav4j/caldav4j/tree/jcr-dev
>
> But it's not in maven yet, since it's a developer branch.So, I was
> wondering how are we going to use the latest caldav4j in openmeetings?
>
> Ankush Mishra
>
> On 08/01/2016 07:51 PM, Maxim Solodovnik wrote:
>
> If I were you I would create final field for the client (if it is
> serializable)
>
> --
> WBR
> Maxim aka solomax
>
>
> --
> Ankush Mishra
>
>
--
WBR
Maxim aka solomax
Re: AppointmentManager Client State clarification
Posted by Ankush Mishra <an...@gmail.com>.
Thanks for the reply but I am not sure if I follow with what you are
saying. As HttpClient is not serializable atleast not the
commons-httpclient, I am not sure what good it would help. Currently in
my AppointmentManager
<https://github.com/TheAntimist/openmeetings/blob/3.2.x/openmeetings-service/src/main/java/org/apache/openmeetings/service/calendar/caldav/AppointmentManager.java>,
I have ensured the creation of only one HttpClient and reusing the old
one, if one already exists. [Code]
<https://github.com/TheAntimist/openmeetings/blob/3.2.x/openmeetings-service/src/main/java/org/apache/openmeetings/service/calendar/caldav/AppointmentManager.java#L75>
But currently the behaviour for the user and password prompts are
whenever the server returns a 401 Unauthorized, but I don't keep the
credentials in the memory only for the period of that sync. And then
remove them. This causes the user to enter the credentials for each sync.
So, I was wondering if I should keep the credentials in memory for the
period of when the CalendarPanel is visible before replace. But it's
just a suggestion, because implementing this, would require me to keep a
Credential or StateTable, for each user in the CalendarPanel, so as to
seperate the data of the each user for different hosts. Personally, I
could implement it, but not sure if it's necessary.
Also, as I stated earlier about caldav4j, the library I modified to use,
currently most of my modifications have been included into the developer
branch here: https://github.com/caldav4j/caldav4j/tree/jcr-dev
But it's not in maven yet, since it's a developer branch.So, I was
wondering how are we going to use the latest caldav4j in openmeetings?
Ankush Mishra
On 08/01/2016 07:51 PM, Maxim Solodovnik wrote:
> If I were you I would create final field for the client (if it is
> serializable)
>
> --
> WBR
> Maxim aka solomax
--
Ankush Mishra