I get Franz's argument about the UserStates (though I (like Stefan) don't
think I would break the rules). It would at least be a bit messy to make a
project negotiation in the outOfSession state.
And for the server I would need to add a new state between outOfSession and
inSession (preparingSession or so). But I need to do that anyway to deal
with multiple requests at the same time.

@Stefan:
Under which circumstances can errors/side effects occur, when a non-host
adds a project to the session. You told me to look at
NonHostAddsProjectWithHostAcceptDelayedTest which deals with 3
participants. Are complications possible when only two participants are in
the session?
If not, the solution would simply be to invite the remaining contacts
(others than server and initiator) after the server received the files.



2013/12/19 Stefan Rossbach <srossb...@arcor.de>

>  On 19.12.2013 16:47, Zieris, Franz wrote:
>
>  Hi Nils,
>
>
>
> > Adding projects while a session is running is problematic, therefore it
> must be done in advance.
>
>
>
> In advance of what? In a normal Saros session, projects are always added
> to running session (i.e. after the SessionNegotiation, see here
> http://www.saros-project.org/userStates).
>
> Well yes, but ONLY the host can do that without errors or unwanted side
> effects.
>
>
>
> > (Right now I see no case in which the server would refuse the files but
> I'd like to be prepared. Tell me if you think this is unnecessary.)
>
> As you said: If there *is no case* you could think of, don’t implement it
> (keep it simple, you ain’t gonna need it, and so on). The best you can do
> is the following: In case you see more than one possible way to implement
> the functionality that is currently wanted, and you want to consider future
> decisions, than you should choose the solution that makes it easier to
> adapt if actually necessary. (Rather theoretical, I know – the simple
> answer is, again, YAGNI).
>
>
>
> > 1. Make the project negotiation available, when no session is running.
> (Shouldn't be too much work)
>
>
>
> Meh, … no. See above: Patrick Schlott introduced the UserStates for a
> reason. Don’t be the first to break these newly introduced rules.
>
> Franz he will not break only rules as this is a plain file transfer. The
> sharing will start afterwards with the files that were transmitted.
>
> E.g: Bob sends Alice project Foo. Alice stores project Foo as Bar in
> directory Foobar. Now Alice starts sharing project Foo, maybe starting a
> session first.
>
> The only thing Nils have to handle are multiple requests at the same time.
>
>
>
> > 2. Automate the server side (IncomingProjectNegotiation, possibly a
> little more work).
>
> This sounds reasonable for the scope of your endeavor/your thesis.
>
>
>
> Franz
>
>
>
> *From:* Nils Bussas [mailto:nils.bus...@gmail.com <nils.bus...@gmail.com>]
>
> *Sent:* Thursday, December 19, 2013 3:40 PM
> *To:* dpp-devel@lists.sourceforge.net
> *Subject:* [DPP-Devel] Send files to server before session start
>
>
>
> Hey guys,
>
> I'm currently implementing a Saros server (in form of adding it as a new
> feature to the regular Saros). My next step is to make it possible for the
> client to send projects (or single files) to the server, so that the server
> can use these when it invites others into the session.
>
> Adding projects while a session is running is problematic, therefore it
> must be done in advance.
>
> When this happens, the server has already agreed that it will start a
> session for the client that is going to send the files.
>
>
>
> I'm not really sure how to do this, so I'd like to have your opinion.
>
> The server should be able to accept or decline the files, therefore the
> file list should be sent before the files. (Right now I see no case in
> which the server would refuse the files but I'd like to be prepared. Tell
> me if you think this is unnecessary.)
>
> When the files are sent, the server will overwrite a local version of the
> same project if it already exists. (At the moment the server can only
> support one session at a time, so no session can be running that include
> the files. (This may/will change in the future and there are multiple ways
> to solve the conflicts that appear when two sessions want to work on the
> same project. I don't intend to decide that in my thesis.))
>
>
>
> I think it woud be to much (unnecessary) work to implement all this from
> scratch when it already exists.
> The project negotiation does pretty much what I need (send file list,
> accept/refuse files, choose where to save them, save them). I would only
> have to alter it in two ways.
>
> 1. Make the project negotiation available, when no session is running.
> (Shouldn't be too much work)
>
> 2. Automate the server side (IncomingProjectNegotiation, possibly a little
> more work).
>
> Do you see any problems with that? If yes, do you have any better
> suggestions?
>
> Regards,
> Nils
>
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics 
> Pro!http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
>
>
>
> _______________________________________________
> DPP-Devel mailing 
> listDPP-Devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/dpp-devel
>
>
>
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
DPP-Devel mailing list
DPP-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dpp-devel

Reply via email to