Smalltalkhub news

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

Smalltalkhub news

Camillo Bruni-3
Nicolas and I improved on last Friday the interaction with Smalltalkhub
- new repository type for Pharo2.0
- cached allFileNames on server side
        - response time reduction: 500ms => 12ms
- added new raw filenames format:
        - see: http://smalltalkhub.com/mc/estebanlm/Voyage/main?format=raw
        - cuts the transferred data size in half
        - reduces parsing overhead on image-side
- fixed a bug in the HTTPRepository where the download would take took long
        - testing if a mcz file exists is now a 10ms action instead of >1s

with the last three fixes applied we have cropped down the response time
from the server to ~15ms. All in all this will make Smalltalkhub a super-fast
Monticello experience!

enjoy!
camillo

Reply | Threaded
Open this post in threaded view
|

Re: Smalltalkhub news

Benjamin Van Ryseghem (Pharo)
Cool cool cool :)

Now the website need a "Import from" part to mmigrate from ss3/squeaksource to SmalltalkHub :)

Ben

On Sep 16, 2012, at 1:18 PM, Camillo Bruni wrote:

> Nicolas and I improved on last Friday the interaction with Smalltalkhub
> - new repository type for Pharo2.0
> - cached allFileNames on server side
> - response time reduction: 500ms => 12ms
> - added new raw filenames format:
> - see: http://smalltalkhub.com/mc/estebanlm/Voyage/main?format=raw
> - cuts the transferred data size in half
> - reduces parsing overhead on image-side
> - fixed a bug in the HTTPRepository where the download would take took long
> - testing if a mcz file exists is now a 10ms action instead of >1s
>
> with the last three fixes applied we have cropped down the response time
> from the server to ~15ms. All in all this will make Smalltalkhub a super-fast
> Monticello experience!
>
> enjoy!
> camillo
>


Reply | Threaded
Open this post in threaded view
|

Re: Smalltalkhub news

oscar
In reply to this post by Camillo Bruni-3
Nice work guys.

Just, one question, I read that Smalltalkhub is using MongoDB. Is that right? How do you do that? There is a Smalltalk port or something for MongoDB.

Cheers.


On Sep 16, 2012, at 8:18 , Camillo Bruni <[hidden email]> wrote:

> Nicolas and I improved on last Friday the interaction with Smalltalkhub
> - new repository type for Pharo2.0
> - cached allFileNames on server side
> - response time reduction: 500ms => 12ms
> - added new raw filenames format:
> - see: http://smalltalkhub.com/mc/estebanlm/Voyage/main?format=raw
> - cuts the transferred data size in half
> - reduces parsing overhead on image-side
> - fixed a bug in the HTTPRepository where the download would take took long
> - testing if a mcz file exists is now a 10ms action instead of >1s
>
> with the last three fixes applied we have cropped down the response time
> from the server to ~15ms. All in all this will make Smalltalkhub a super-fast
> Monticello experience!
>
> enjoy!
> camillo


Reply | Threaded
Open this post in threaded view
|

Re: Smalltalkhub news

EstebanLM
driver: 


mapper: 


cheers,
Esteban


On Sep 16, 2012, at 3:15 PM, Oscar E A Callaú <[hidden email]> wrote:

Nice work guys.

Just, one question, I read that Smalltalkhub is using MongoDB. Is that right? How do you do that? There is a Smalltalk port or something for MongoDB.

Cheers.


On Sep 16, 2012, at 8:18 , Camillo Bruni <[hidden email]> wrote:

Nicolas and I improved on last Friday the interaction with Smalltalkhub
- new repository type for Pharo2.0
- cached allFileNames on server side
- response time reduction: 500ms => 12ms
- added new raw filenames format:
- see: http://smalltalkhub.com/mc/estebanlm/Voyage/main?format=raw
- cuts the transferred data size in half
- reduces parsing overhead on image-side
- fixed a bug in the HTTPRepository where the download would take took long
- testing if a mcz file exists is now a 10ms action instead of >1s

with the last three fixes applied we have cropped down the response time
from the server to ~15ms. All in all this will make Smalltalkhub a super-fast
Monticello experience!

enjoy!
camillo



Reply | Threaded
Open this post in threaded view
|

Re: Smalltalkhub news

philippeback
In reply to this post by Benjamin Van Ryseghem (Pharo)
Very cool.

I'll give it a shot.



2012/9/16 Benjamin <[hidden email]>:

> Cool cool cool :)
>
> Now the website need a "Import from" part to mmigrate from ss3/squeaksource to SmalltalkHub :)
>
> Ben
>
> On Sep 16, 2012, at 1:18 PM, Camillo Bruni wrote:
>
>> Nicolas and I improved on last Friday the interaction with Smalltalkhub
>> - new repository type for Pharo2.0
>> - cached allFileNames on server side
>>       - response time reduction: 500ms => 12ms
>> - added new raw filenames format:
>>       - see: http://smalltalkhub.com/mc/estebanlm/Voyage/main?format=raw
>>       - cuts the transferred data size in half
>>       - reduces parsing overhead on image-side
>> - fixed a bug in the HTTPRepository where the download would take took long
>>       - testing if a mcz file exists is now a 10ms action instead of >1s
>>
>> with the last three fixes applied we have cropped down the response time
>> from the server to ~15ms. All in all this will make Smalltalkhub a super-fast
>> Monticello experience!
>>
>> enjoy!
>> camillo
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Smalltalkhub news

Stéphane Ducasse
In reply to this post by Camillo Bruni-3
Excellent!

Stef

On Sep 16, 2012, at 1:18 PM, Camillo Bruni wrote:

> Nicolas and I improved on last Friday the interaction with Smalltalkhub
> - new repository type for Pharo2.0
> - cached allFileNames on server side
> - response time reduction: 500ms => 12ms
> - added new raw filenames format:
> - see: http://smalltalkhub.com/mc/estebanlm/Voyage/main?format=raw
> - cuts the transferred data size in half
> - reduces parsing overhead on image-side
> - fixed a bug in the HTTPRepository where the download would take took long
> - testing if a mcz file exists is now a 10ms action instead of >1s
>
> with the last three fixes applied we have cropped down the response time
> from the server to ~15ms. All in all this will make Smalltalkhub a super-fast
> Monticello experience!
>
> enjoy!
> camillo
>


Reply | Threaded
Open this post in threaded view
|

Re: Smalltalkhub news

Sven Van Caekenberghe-2
In reply to this post by Camillo Bruni-3
Good work !

Where can the code be found/seen ?

I am especially interested in the last point. Has it something to do with (using) Zn ?

--
Sven Van Caekenberghe
http://stfx.eu
Smalltalk is the Red Pill



On 16 Sep 2012, at 13:18, Camillo Bruni <[hidden email]> wrote:

> Nicolas and I improved on last Friday the interaction with Smalltalkhub
> - new repository type for Pharo2.0
> - cached allFileNames on server side
> - response time reduction: 500ms => 12ms
> - added new raw filenames format:
> - see: http://smalltalkhub.com/mc/estebanlm/Voyage/main?format=raw
> - cuts the transferred data size in half
> - reduces parsing overhead on image-side
> - fixed a bug in the HTTPRepository where the download would take took long
> - testing if a mcz file exists is now a 10ms action instead of >1s
>
> with the last three fixes applied we have cropped down the response time
> from the server to ~15ms. All in all this will make Smalltalkhub a super-fast
> Monticello experience!
>
> enjoy!
> camillo


Reply | Threaded
Open this post in threaded view
|

Re: Smalltalkhub news

Camillo Bruni-3

On 2012-09-16, at 21:29, Sven Van Caekenberghe <[hidden email]> wrote:

> Good work !
>
> Where can the code be found/seen ?

all in the latest pharo SmalltalkHubRepository browse.

> I am especially interested in the last point. Has it something to do with (using) Zn ?

yes, we basically did a HEAD request and returned false on 404, however
Zn does 3 or so retries, and thus makes everything slow :). I don't know what
the side-effects are, but we reduce the retryCount to 0, to get low response times.

I thought that upon a valid 404 response there is no retry needed? (but I guess
I miss something here :P)
Reply | Threaded
Open this post in threaded view
|

Re: Smalltalkhub news

Sven Van Caekenberghe-2

On 16 Sep 2012, at 21:56, Camillo Bruni <[hidden email]> wrote:

>> I am especially interested in the last point. Has it something to do with (using) Zn ?
>
> yes, we basically did a HEAD request and returned false on 404, however
> Zn does 3 or so retries, and thus makes everything slow :). I don't know what
> the side-effects are, but we reduce the retryCount to 0, to get low response times.
>
> I thought that upon a valid 404 response there is no retry needed? (but I guess
> I miss something here :P)

The reason ZnClient keeps on retrying on 404 is because you probably had #enforceHttpSuccess true as part of #systemPolicy and only 2xx response are considered a success.

But this is an interesting use case: basically 404 is a valid response here. I'll have to think about that so more.

Thanks for pushing this and letting me know.

--
Sven Van Caekenberghe
http://stfx.eu
Smalltalk is the Red Pill




Reply | Threaded
Open this post in threaded view
|

Re: Smalltalkhub news

Camillo Bruni-3

On 2012-09-16, at 22:50, Sven Van Caekenberghe <[hidden email]> wrote:

>
> On 16 Sep 2012, at 21:56, Camillo Bruni <[hidden email]> wrote:
>
>>> I am especially interested in the last point. Has it something to do with (using) Zn ?
>>
>> yes, we basically did a HEAD request and returned false on 404, however
>> Zn does 3 or so retries, and thus makes everything slow :). I don't know what
>> the side-effects are, but we reduce the retryCount to 0, to get low response times.
>>
>> I thought that upon a valid 404 response there is no retry needed? (but I guess
>> I miss something here :P)
>
> The reason ZnClient keeps on retrying on 404 is because you probably had #enforceHttpSuccess true as part of #systemPolicy and only 2xx response are considered a success.

ah right, that will do it!

> But this is an interesting use case: basically 404 is a valid response here. I'll have to think about that so more.

well now I know, so I'm fine by manually changing it :P
Reply | Threaded
Open this post in threaded view
|

Re: Smalltalkhub news

Igor Stasenko
yeah, i think it is pointless to retry if you get 404 "not found"
response. Usually (of course if web server conforms to HTTP RFC), this
means that requested resource is really not there and will not be
there anytime soon :)

On 16 September 2012 23:10, Camillo Bruni <[hidden email]> wrote:

>
> On 2012-09-16, at 22:50, Sven Van Caekenberghe <[hidden email]> wrote:
>
>>
>> On 16 Sep 2012, at 21:56, Camillo Bruni <[hidden email]> wrote:
>>
>>>> I am especially interested in the last point. Has it something to do with (using) Zn ?
>>>
>>> yes, we basically did a HEAD request and returned false on 404, however
>>> Zn does 3 or so retries, and thus makes everything slow :). I don't know what
>>> the side-effects are, but we reduce the retryCount to 0, to get low response times.
>>>
>>> I thought that upon a valid 404 response there is no retry needed? (but I guess
>>> I miss something here :P)
>>
>> The reason ZnClient keeps on retrying on 404 is because you probably had #enforceHttpSuccess true as part of #systemPolicy and only 2xx response are considered a success.
>
> ah right, that will do it!
>
>> But this is an interesting use case: basically 404 is a valid response here. I'll have to think about that so more.
>
> well now I know, so I'm fine by manually changing it :P



--
Best regards,
Igor Stasenko.

Reply | Threaded
Open this post in threaded view
|

Re: Smalltalkhub news

Sven Van Caekenberghe-2

On 17 Sep 2012, at 11:05, Igor Stasenko <[hidden email]> wrote:

> yeah, i think it is pointless to retry if you get 404 "not found"
> response. Usually (of course if web server conforms to HTTP RFC), this
> means that requested resource is really not there and will not be
> there anytime soon :)

I decided to only do retries on NetworkError, ZnParseError for now, we'll see how it goes.
The ifFail block will be triggered on any Error.

> On 16 September 2012 23:10, Camillo Bruni <[hidden email]> wrote:
>>
>> On 2012-09-16, at 22:50, Sven Van Caekenberghe <[hidden email]> wrote:
>>
>>>
>>> On 16 Sep 2012, at 21:56, Camillo Bruni <[hidden email]> wrote:
>>>
>>>>> I am especially interested in the last point. Has it something to do with (using) Zn ?
>>>>
>>>> yes, we basically did a HEAD request and returned false on 404, however
>>>> Zn does 3 or so retries, and thus makes everything slow :). I don't know what
>>>> the side-effects are, but we reduce the retryCount to 0, to get low response times.
>>>>
>>>> I thought that upon a valid 404 response there is no retry needed? (but I guess
>>>> I miss something here :P)
>>>
>>> The reason ZnClient keeps on retrying on 404 is because you probably had #enforceHttpSuccess true as part of #systemPolicy and only 2xx response are considered a success.
>>
>> ah right, that will do it!
>>
>>> But this is an interesting use case: basically 404 is a valid response here. I'll have to think about that so more.
>>
>> well now I know, so I'm fine by manually changing it :P

--
Sven Van Caekenberghe
http://stfx.eu
Smalltalk is the Red Pill




Reply | Threaded
Open this post in threaded view
|

Re: Smalltalkhub news

Camillo Bruni-3

On 2012-09-17, at 11:18, Sven Van Caekenberghe <[hidden email]> wrote:

>
> On 17 Sep 2012, at 11:05, Igor Stasenko <[hidden email]> wrote:
>
>> yeah, i think it is pointless to retry if you get 404 "not found"
>> response. Usually (of course if web server conforms to HTTP RFC), this
>> means that requested resource is really not there and will not be
>> there anytime soon :)
>
> I decided to only do retries on NetworkError, ZnParseError for now, we'll see how it goes.
> The ifFail block will be triggered on any Error.

sounds reasonable :)
Reply | Threaded
Open this post in threaded view
|

Re: Smalltalkhub news

fstephany
In reply to this post by Camillo Bruni-3
Is there a Metacello configuration for it?
I'm trying to load it by hand but guessing the dependencies is tricky
for me.

On 16/09/12 12:56, Camillo Bruni wrote:

>
> On 2012-09-16, at 21:29, Sven Van Caekenberghe <[hidden email]> wrote:
>
>> Good work !
>>
>> Where can the code be found/seen ?
>
> all in the latest pharo SmalltalkHubRepository browse.
>
>> I am especially interested in the last point. Has it something to do with (using) Zn ?
>
> yes, we basically did a HEAD request and returned false on 404, however
> Zn does 3 or so retries, and thus makes everything slow :). I don't know what
> the side-effects are, but we reduce the retryCount to 0, to get low response times.
>
> I thought that upon a valid 404 response there is no retry needed? (but I guess
> I miss something here :P)
>

--
http://tulipemoutarde.be
CA: +1 778 558 3225
BE: +32 65 709 131

Reply | Threaded
Open this post in threaded view
|

Re: Smalltalkhub news

Nicolas Petton

No, there's no configuration yet.

Nico

On Wed, 19 Sep 2012 15:05:10 -0700, Francois Stephany <[hidden email]> wrote:

> Is there a Metacello configuration for it?
> I'm trying to load it by hand but guessing the dependencies is tricky
> for me.
>
> On 16/09/12 12:56, Camillo Bruni wrote:
> >
> > On 2012-09-16, at 21:29, Sven Van Caekenberghe <[hidden email]> wrote:
> >
> >> Good work !
> >>
> >> Where can the code be found/seen ?
> >
> > all in the latest pharo SmalltalkHubRepository browse.
> >
> >> I am especially interested in the last point. Has it something to do with (using) Zn ?
> >
> > yes, we basically did a HEAD request and returned false on 404, however
> > Zn does 3 or so retries, and thus makes everything slow :). I don't know what
> > the side-effects are, but we reduce the retryCount to 0, to get low response times.
> >
> > I thought that upon a valid 404 response there is no retry needed? (but I guess
> > I miss something here :P)
> >
>
> --
> http://tulipemoutarde.be
> CA: +1 778 558 3225
> BE: +32 65 709 131
>

--
Nicolas Petton
http://nicolas-petton.fr

Reply | Threaded
Open this post in threaded view
|

Re: Smalltalkhub news

fstephany
Ok!

I've managed to load it but haven't tried to run it (yet). I almost gave
up before realising that KO is the prefix used by Kalingrad :)

It's cool to browse a real project using Seaside and Mongo. The way
Smalltalkhub maps Mongo and Smalltalk objects is interesting. It seems
to be more explicit than the Voyage approach. Have you considered to use
Voyage or to extract the smalltalkhub mapper to a indenpendent package
(a bit like mongoid, moped and origin in ruby[1])?

Anyway, thanks for open sourcing it!

Fa

[1]http://mongoid.org/en/mongoid/index.html

On 20/09/12 03:32, Nicolas Petton wrote:

>
> No, there's no configuration yet.
>
> Nico
>
> On Wed, 19 Sep 2012 15:05:10 -0700, Francois Stephany <[hidden email]> wrote:
>> Is there a Metacello configuration for it?
>> I'm trying to load it by hand but guessing the dependencies is tricky
>> for me.
>>
>> On 16/09/12 12:56, Camillo Bruni wrote:
>>>
>>> On 2012-09-16, at 21:29, Sven Van Caekenberghe <[hidden email]> wrote:
>>>
>>>> Good work !
>>>>
>>>> Where can the code be found/seen ?
>>>
>>> all in the latest pharo SmalltalkHubRepository browse.
>>>
>>>> I am especially interested in the last point. Has it something to do with (using) Zn ?
>>>
>>> yes, we basically did a HEAD request and returned false on 404, however
>>> Zn does 3 or so retries, and thus makes everything slow :). I don't know what
>>> the side-effects are, but we reduce the retryCount to 0, to get low response times.
>>>
>>> I thought that upon a valid 404 response there is no retry needed? (but I guess
>>> I miss something here :P)
>>>

Reply | Threaded
Open this post in threaded view
|

Re: Smalltalkhub news

Nicolas Petton

Yes, in fact with Esteban we thought about merging our work or maybe I
will drop my layer and use Voyage.

Nico

On Thu, 20 Sep 2012 10:30:30 -0700, Francois Stephany <[hidden email]> wrote:

> Ok!
>
> I've managed to load it but haven't tried to run it (yet). I almost gave
> up before realising that KO is the prefix used by Kalingrad :)
>
> It's cool to browse a real project using Seaside and Mongo. The way
> Smalltalkhub maps Mongo and Smalltalk objects is interesting. It seems
> to be more explicit than the Voyage approach. Have you considered to use
> Voyage or to extract the smalltalkhub mapper to a indenpendent package
> (a bit like mongoid, moped and origin in ruby[1])?
>
> Anyway, thanks for open sourcing it!
>
> Fa
>
> [1]http://mongoid.org/en/mongoid/index.html
>
> On 20/09/12 03:32, Nicolas Petton wrote:
> >
> > No, there's no configuration yet.
> >
> > Nico
> >
> > On Wed, 19 Sep 2012 15:05:10 -0700, Francois Stephany <[hidden email]> wrote:
> >> Is there a Metacello configuration for it?
> >> I'm trying to load it by hand but guessing the dependencies is tricky
> >> for me.
> >>
> >> On 16/09/12 12:56, Camillo Bruni wrote:
> >>>
> >>> On 2012-09-16, at 21:29, Sven Van Caekenberghe <[hidden email]> wrote:
> >>>
> >>>> Good work !
> >>>>
> >>>> Where can the code be found/seen ?
> >>>
> >>> all in the latest pharo SmalltalkHubRepository browse.
> >>>
> >>>> I am especially interested in the last point. Has it something to do with (using) Zn ?
> >>>
> >>> yes, we basically did a HEAD request and returned false on 404, however
> >>> Zn does 3 or so retries, and thus makes everything slow :). I don't know what
> >>> the side-effects are, but we reduce the retryCount to 0, to get low response times.
> >>>
> >>> I thought that upon a valid 404 response there is no retry needed? (but I guess
> >>> I miss something here :P)
> >>>
>

--
Nicolas Petton
http://nicolas-petton.fr

Reply | Threaded
Open this post in threaded view
|

Re: Smalltalkhub news

EstebanLM
in fact, I already dropped old Voyage session cache for the one in SmalltalkHub, which was cooler than mine :)
now is turn to Nico to check what can he use from Voyage, and if that makes sense ;)

Esteban


On Sep 21, 2012, at 11:05 AM, Nicolas Petton <[hidden email]> wrote:

>
> Yes, in fact with Esteban we thought about merging our work or maybe I
> will drop my layer and use Voyage.
>
> Nico
>
> On Thu, 20 Sep 2012 10:30:30 -0700, Francois Stephany <[hidden email]> wrote:
>> Ok!
>>
>> I've managed to load it but haven't tried to run it (yet). I almost gave
>> up before realising that KO is the prefix used by Kalingrad :)
>>
>> It's cool to browse a real project using Seaside and Mongo. The way
>> Smalltalkhub maps Mongo and Smalltalk objects is interesting. It seems
>> to be more explicit than the Voyage approach. Have you considered to use
>> Voyage or to extract the smalltalkhub mapper to a indenpendent package
>> (a bit like mongoid, moped and origin in ruby[1])?
>>
>> Anyway, thanks for open sourcing it!
>>
>> Fa
>>
>> [1]http://mongoid.org/en/mongoid/index.html
>>
>> On 20/09/12 03:32, Nicolas Petton wrote:
>>>
>>> No, there's no configuration yet.
>>>
>>> Nico
>>>
>>> On Wed, 19 Sep 2012 15:05:10 -0700, Francois Stephany <[hidden email]> wrote:
>>>> Is there a Metacello configuration for it?
>>>> I'm trying to load it by hand but guessing the dependencies is tricky
>>>> for me.
>>>>
>>>> On 16/09/12 12:56, Camillo Bruni wrote:
>>>>>
>>>>> On 2012-09-16, at 21:29, Sven Van Caekenberghe <[hidden email]> wrote:
>>>>>
>>>>>> Good work !
>>>>>>
>>>>>> Where can the code be found/seen ?
>>>>>
>>>>> all in the latest pharo SmalltalkHubRepository browse.
>>>>>
>>>>>> I am especially interested in the last point. Has it something to do with (using) Zn ?
>>>>>
>>>>> yes, we basically did a HEAD request and returned false on 404, however
>>>>> Zn does 3 or so retries, and thus makes everything slow :). I don't know what
>>>>> the side-effects are, but we reduce the retryCount to 0, to get low response times.
>>>>>
>>>>> I thought that upon a valid 404 response there is no retry needed? (but I guess
>>>>> I miss something here :P)
>>>>>
>>
>
> --
> Nicolas Petton
> http://nicolas-petton.fr
>


Reply | Threaded
Open this post in threaded view
|

Re: Smalltalkhub news

Nicolas Petton

I really like the abstraction that Voyage provides. We could check if it
would make sense to use it for SmalltalkHub. I really hate duplicated
efforts.

Nico

On Fri, 21 Sep 2012 11:11:33 +0200, Esteban Lorenzano <[hidden email]> wrote:

> in fact, I already dropped old Voyage session cache for the one in SmalltalkHub, which was cooler than mine :)
> now is turn to Nico to check what can he use from Voyage, and if that makes sense ;)
>
> Esteban
>
>
> On Sep 21, 2012, at 11:05 AM, Nicolas Petton <[hidden email]> wrote:
>
> >
> > Yes, in fact with Esteban we thought about merging our work or maybe I
> > will drop my layer and use Voyage.
> >
> > Nico
> >
> > On Thu, 20 Sep 2012 10:30:30 -0700, Francois Stephany <[hidden email]> wrote:
> >> Ok!
> >>
> >> I've managed to load it but haven't tried to run it (yet). I almost gave
> >> up before realising that KO is the prefix used by Kalingrad :)
> >>
> >> It's cool to browse a real project using Seaside and Mongo. The way
> >> Smalltalkhub maps Mongo and Smalltalk objects is interesting. It seems
> >> to be more explicit than the Voyage approach. Have you considered to use
> >> Voyage or to extract the smalltalkhub mapper to a indenpendent package
> >> (a bit like mongoid, moped and origin in ruby[1])?
> >>
> >> Anyway, thanks for open sourcing it!
> >>
> >> Fa
> >>
> >> [1]http://mongoid.org/en/mongoid/index.html
> >>
> >> On 20/09/12 03:32, Nicolas Petton wrote:
> >>>
> >>> No, there's no configuration yet.
> >>>
> >>> Nico
> >>>
> >>> On Wed, 19 Sep 2012 15:05:10 -0700, Francois Stephany <[hidden email]> wrote:
> >>>> Is there a Metacello configuration for it?
> >>>> I'm trying to load it by hand but guessing the dependencies is tricky
> >>>> for me.
> >>>>
> >>>> On 16/09/12 12:56, Camillo Bruni wrote:
> >>>>>
> >>>>> On 2012-09-16, at 21:29, Sven Van Caekenberghe <[hidden email]> wrote:
> >>>>>
> >>>>>> Good work !
> >>>>>>
> >>>>>> Where can the code be found/seen ?
> >>>>>
> >>>>> all in the latest pharo SmalltalkHubRepository browse.
> >>>>>
> >>>>>> I am especially interested in the last point. Has it something to do with (using) Zn ?
> >>>>>
> >>>>> yes, we basically did a HEAD request and returned false on 404, however
> >>>>> Zn does 3 or so retries, and thus makes everything slow :). I don't know what
> >>>>> the side-effects are, but we reduce the retryCount to 0, to get low response times.
> >>>>>
> >>>>> I thought that upon a valid 404 response there is no retry needed? (but I guess
> >>>>> I miss something here :P)
> >>>>>
> >>
> >
> > --
> > Nicolas Petton
> > http://nicolas-petton.fr
> >
>
>

--
Nicolas Petton
http://nicolas-petton.fr