Biggest Fake Conference in Computer Science

Biggest Fake Conference in Computer Science

We are researchers from different parts of the world and conducted a study on the world’s biggest 
bogus computer science conference WORLDCOMP  http://sites.google.com/site/worlddump1 
organized by Prof. Hamid Arabnia from University of Georgia, USA.

We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to 
WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that 
paper include: 

(1). Binary logic is fuzzy logic and vice versa
(2). Pascal developed fuzzy logic
(3). Object oriented languages do not exhibit any polymorphism or inheritance
(4). TCP and IP are synonyms and are part of OSI model 
(5). Distributed systems deal with only one computer
(6). Laptop is an example for a super computer
(7). Operating system is an example for computer hardware

Also, our paper did not express any conceptual meaning.  However, it was accepted both the times 
without any modifications (and without any reviews) and we were invited to submit the final paper 
and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than 
making Prof. Hamid Arabnia richer. After that, we received few reminders from WORLDCOMP to pay 
the fee but we never responded. This fake paper is different from the two fake papers already published 
(see https://sites.google.com/site/worlddump4 for details) in WORLDCOMP.

We MUST say that you should look at the above website if you have any thoughts of participating in
WORLDCOMP.  DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings 
since 2011 due to its fakeness. See
http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for
of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of

Re: [Python-Dev] wsgi validator with asynchronous handlers/servers

On Sat, Mar 23, 2013 at 7:30 PM, Luca Sbardella
<luca.sbardella@...> wrote:
>PJ Eby wrote:
>> The validator is correct for the spec.  You *must* call
>> start_response() before yielding any strings at all.
>
>
> Thanks for response PJ,
> that is what I, unfortunately, didn't want to hear, the validator being
> correct for the "spec" means I can't use it for my asynchronous stuff, which
> is a shame ((
> But why commit to send headers when you may not know about your response?
> Sorry if this is the wrong mailing list for the issue, I'll adjust as I go
> along.

Because async was added as an afterthought to WSGI about nine years
ago, and we didn't get it right, but it long ago was too late to do
anything about it.  A properly async WSGI implementation will probably
have to wait for Tulip (Guido's project to bring a standard async
programming API to Python).
_______________________________________________
Web-SIG mailing list
Web-SIG@...
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/gcpw-web-sig%40m.gmane.org

Re: WSGI Lite

[Please follow-up to web-sig, rather than emailing me privately.  Thanks.]

On Fri, Mar 22, 2013 at 6:52 AM, Simon Yarde <simonyarde@...> wrote:
> If I have two layers of middleware, can I trust the intermediate layer has
> not altered or wiped out any dotted-name keys in the environ prior to
> calling the layer below?

No; middleware isn't even required to pass the same environ object to
a nested app.  But most middleware will, and won't delete things in
it.

> I discovered your article on WSGI Lite as I was having similar ideas about
> binding for the purposes you describe; auth, session, cart etc. and keeping
> the app code minimal. I was aiming to find a way to allow objects
> initialised with an environ to interrupt execution at initialisation time
> and return a response. I felt something like this was needed to avoid doing
> this at the top of every app:
>
>     def app(input=Parse(XML, JSON),
> auth=Auth):
>        if not input:
>            return NotAcceptableResponse
>         if not auth:
>             return UnAuthorisedResponse
>
> I was playing around with a factory-method approach that would either return
> an instance or a 3-tuple response; the binding process would identify the
> result as an instance and add it to the calling args, or interrupt the  call
> and return it.

Re: WSGI Lite

On Mon, Mar 18, 2013 at 1:08 PM, Simon Yarde <simonyarde@...> wrote:
> If I understand correctly, one of the goals of WSGI Lite is to keep the environ out of middleware and app code
to prevent modification.

No.  You are *allowed* to modify the environment, that's part of the
WSGI spec.  What you *can't* do is trust that nobody *else* will
modify it.  Which is why you can't use the environment to communicate
with middleware, only objects passed along in the environment.

For example, if middleware does env['foobar']=[], it's okay for a
called app to modify that list, as long as the middleware saves a
reference to it and doesn't try to pull it out of the environ later,
e.g.:

     def middleware(...):
          my_list = []
          env['foobar'] = my_list
          app(env)
          if my_list: ....blah

But you must NEVER do this:

     def middleware(...):
          app(env)
          if env['foobar']: ....blah

Even if you were the one who put 'foobar' into the env.

WSGI Lite's argument binding protocol addresses a different problem,
which is that after you call app(env), it's too late for you to get

WebTest Paris Sprint

Hi!

A quick mail to let you know that we will have a sprint[1] about 
WebTest[2] at Bearstech, Paris, end of February.

Register yourself on the wiki page[2] if you want to join us!

You can add your own topic if you need some features. This will be 
discussed during the sprint.

Feel free to ask any questions. Also I can try to help you find a 
couch/room for your visit if needed.

I know that's the event is in a month. And I'm sorry that, for some 
reasons, I have to announce it that late. Hope you'll be able to come 
though!

Happy hacking!

Regards,

--
Gael

[1] http://bearstech.com/actualites/webtest-paris-sprint
[2] http://webtest.readthedocs.org/en/latest/
[3] https://github.com/Pylons/webtest/wiki/ParisSprint2013
_______________________________________________
Web-SIG mailing list
Web-SIG@...

WSGI apps on IIS

From my blog post: http://rpatterson.net/software/wsgi-apps-on-iis

The `iiswsgi`_ module implements a FastCGI to `WSGI`_ gateway that is
compatible with `IIS`_'s variation of the `FastCGI protocol`_.  It also
provides `distutils`_ commands for building, distributing and installing
`Microsoft Web Deploy`_ (MSDeploy) packages through the `Web Platform
Installer`_ (WebPI).

The goals of the code in `iiswsgi`_ are to do the following for
deploying WSGI apps on IIS:

* make it open source as far as possible, right up to IIS
* be Pythonic as far as possible, right up to the MSDeploy packaging
* re-use our existing tool-chain for distributing packages
* share the maintenance burden for a WSGI on Windows story across the
  community

For the `Plone`_ project, it's always been simultaneously a necessity
that we support a Windows deployment story and one of our biggest pain
points.  The Windows installers have always been very different from
the other installers.  They have had different layouts from our user
and developer documentation and even from each other.  They have never
been maintained or supported by more than one entity, either a company
or an individual, and as such have often and ultimately languished.
And as for the poor individuals who have tackled the Windows
installers, they have almost always burned out and can no longer
provide any significant Windows support at all.  This is not a healthy
open source community dynamic.  And yet there is wide consensus that
it's not an option *not* to have a Windows deployment story.

resources for porting wsgi apps from python 2 to 3

I was at pyconuk over the weekend and came away from that all
refreshed and wanting to hack. That combined with the recent release
of Python 3.3 had me deciding it was time to start porting
TiddlyWeb[1] to Python3.

I'm having progress along some lines and a bit of a mess along others.
The major holdback right now are dependencies which are not yet
ported, which I'd like to port as well, but proving hard to port
because they have test dependencies which themselves are not yet
ported.

A medium sized issue is related to how WSGI is supposed to behave in
Python3. TiddlyWeb is its own framework and doesn't use webob or
werkzeug, etc. It does dispatch with selector, but other than
that processes handling headers and request body as it gets them from
the server. For tests it uses wsgi-intercept[2] to simulate a web
server. I've volunteered to port that (having already done some minor
work on it in the past) so need to get clear and the disposition of
bytes or strings in headers and bodies of both requests and responses.

I have a few questions that I'm hoping people here will help me
answer, or at least point me in the right direction. I'll be happy to
summarize the results after the discussion has tailed off.[3]

I've looked over pep 3333 and don't some other reading, but I don't feel
fully confident. The question is mostly around what part of the stack
should be uptight. In the below when I say "bytes" and "str" I mean the
Python 3 types.

Sarge - progress update

Hello!

Here's a progress update on "sarge", the deployment tool. Turns out I
was trying to address too many concerns at once, so I focussed on the
core problem: managing the lifecycle of a version of the application.

http://mgax.github.com/sarge/

Sarge acts as container for "instances". An instance can be *created*,
then you install code and configure stuff; you can then *start* and
*stop* it, and when a new version is ready, *destroy* the old one.
There's also a *run* command to bring up a REPL or execute custom
commands. Some documentation exists: http://mgax.github.com/sarge/

Instances are independent, so you can run them simultaneously; this
allows for different instances for different jobs (web, worker, cron
script) and also things like rolling back a failed deployment or
zero-downtime upgrade. I'm using this, for a couple of projects, in
production, today.

There's an example fabfile in the repo (deploy/complex_fabfile.py), but
it's way more complex than it should be. Much of that logic should
probably be handled by sarge itself.

Thoughts, ideas?

Cheers,
-- Alex

_______________________________________________

Re: question about connection pool, task queue in WSGI

Please keep replies in the mailing list.

Graham

On 13 July 2012 07:18, est <electronixtar <at> gmail.com> wrote:
> Thanks for the answer. That's very helpful info.
>
>>  Only by changing the Django code base from memory. Better off asking
> on the Django users list.
>
> Is my idea was good or bad? (make wsgi handle connection pools, instead of
> wsgi apps)
>
> I read Tarek Ziadé last month's experiement of re-use tcp port by specify
> socket FDs. It's awesome idea and code btw. I have couple of questions about
> it:
>
> 1. In theory, I presume it's also possible with db connections? (After wsgi
> hosting worker ended, handle the db connection FD to the next wsgi worker)
>
> 2. Is the socket FD the same mechanism like nginx? If you upgrade nginx
> binary, restart nginx, the existing http connection won't break.
>
> 3. Is my following understanding of wsgi model right?
>
> A wsgi worker process runs the wsgi app (like django), multiple requests are
> handled by the same process, the django views process these requests and
> returns responses within the same process (possible in fork or threaded way,
> or even both?). After a defined number of requests the wsgi worker
> terminates and spawns the next wsgi worker process.

question about connection pool, task queue in WSGI

_______________________________________________
Web-SIG mailing list
Web-SIG@...
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/gcpw-web-sig%40m.gmane.org

Sarge - a web application hosting tool

Hi folks,

I've been tinkering with a tool for hosting web applications. It aims to make deployment easier by
automating configuration on the server: starting up processes, linking them to databases, configuring
the front-end web server, etc. Many ideas are borrowed from Ian Bicking's proposal from April 2011[1].

http://alex-morega.github.com/Sarge/

On the server, Sarge reads a "hosting" configuration file for each "deployment". This describes
resources available to the application (e.g. database), along with a domain name, public HTTP port, etc.
The "guest" application is deployed with its own configuration file that provides a urlmap, service
requirements, entry points. These configuration files are still underspecified; apppkg[2] may be a
good model for them.

Processes are started with supervisor[3], and nginx is assumed as http server. For the application,
services (e.g. database access) will be provided via plugins, but the plugin API is not very useful yet.

The code is thoroughly covered in unit tests. There is a small set of integration tests that run against a
vagrant[4] virtual machine. Also there is the beginnings of a documentation, including a tutorial[5]
that should give you an idea of the deployment workflow.

Feedback is most welcome! I've started work out of personal frustration of having to copy/paste fabric
commands between projects, but I'd love for this tool to be widely useful.

Cheers,
-- Alex

[1] http://mail.python.org/pipermail/web-sig/2011-April/005009.html
[2] https://github.com/ianb/apppkg/
[3] http://supervisord.org/
[4] http://vagrantup.com/
[5] http://alex-morega.github.com/Sarge/tutorial.html

_______________________________________________
Web-SIG mailing list
Web-SIG@...
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/gcpw-web-sig%40m.gmane.org