Re: django-amp-tools project improvement

['Adam Johnson' via Django developers (Contributions to Django itself)]

Hi Pratham,

Sorry to be a bit of a downer here...

The django-amp-tools project is not an official django project and has not
been updated for a while (it doesn't support *any* currently supported
Django versions). It's also not particularly popular - 65 stars - and in
general I feel like AMP is in decline. Better CDN's and HTTP/2+3 allow for
faster delivery of vanilla HTML. So I'm not sure we could support a project
contributing to django-amp-tools. That said I'm prepared to be proven
wrong, I know big news sites tend to still support AMP so there's probably
some value there.

Did you check out the wiki page on GSoC and its suggested projects?
https://code.djangoproject.com/wiki/SummerOfCode2021

Thanks,

Adam


On Wed, 7 Apr 2021 at 23:15, Pratham Jangra  wrote:

> Hello developers
>
> This is Pratham Jangra, a Computer Science & Engineering undergrad
> sophomore.
>
> For GSoC 2021, I am making a proposal to solve some problems in the
> django-amp-tools project. The most important one is to create a library
> for auto-parsing HTML tags.
>
>
>
> Importance: As we all know AMP is used by a massive amount of websites
> for webpages to load faster and get pages optimized for mobile browsing.
> Nowadays AMP is heavily used for user-first websites, stories, ads, emails.
> It is widely used for SEO in websites as Google prefers it and gives the
> website a higher ranking.
>
>
>
> Problems/Ideas: AMP uses equivalent HTML tags to optimize a particular
> webpage. But there are still some issues yet to be resolved as follows:
>
>-
>
>AMP is based on components
>-
>
>   Not all tags have equivalent representation in HTML which is a big
>   issue because day by day content is increasing on AMP pages and we will
>   eventually need those tags to render the pages. This is the problem I 
> have
>   faced personally while using AMP boilerplate for a website. There is no
>   amplify tag equivalent.
>   -
>
>   Translation is still a big issue for AMP.  Currently all HTML
>   cannot be translated.
>   -
>
>   Automatic parsing: If there is a way to automatically parse all
>   tags of HTML then most of the issues of equivalent representation in AMP
>   will be solved. for e.g. . All we would need to do is create a 
> library
>   to automatically create an AMP-equivalent page of the existing HTML 
> page.
>   -
>
>   Need for stabilize the parsing.
>
> I did my research as much as possible but still some issues are there and
> we can create a new library for auto-parsing the tags in normal HTML. My
> proposal is still in work and I would really appreciate feedback and
> suggestions on these issues. Please advise me to implement any other
> features and if there is anything wrong in the whole idea. I am open to any
> new ideas; and please correct me if I have missed anything in the whole
> idea. Thank you.
>
>
>
> Regards
>
> Pratham Jangra
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/fa290e47-6ee9-4136-9a72-368fdc2da9ddn%40googlegroups.com
> 
> .
>


-- 
Adam

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM03rumC8nYN4T8F8XDqjdBy_MQd7uq8SFV4UA%2BoJ%3Dp20g%40mail.gmail.com.

Re: Adding ability to choose AutoField type (signed vs unsigned)

['Adam Johnson' via Django developers (Contributions to Django itself)]

Okay fair enough, it wouldn't be much work to ship a PositiveBigAutoField
class.


On Wed, 7 Apr 2021 at 08:29, Florian Apolloner 
wrote:

> On Tuesday, April 6, 2021 at 7:08:06 PM UTC+2 Adam Johnson wrote:
>
>> I also don't think this is necessary any more and can be closed.
>>
>>
>>> An explicit `id = PositiveBigIntegerField(...)` workaround would be fine
>>> to be honest, for those that need it.
>>
>>
>> I also would like to meet the django app that *does* need it (for
>> non-silly reasons like deciding to start ID's near 2^63).
>>
>
> Since you have asked: It is required if you want to store a x509
> certificate serial number as is. We indeed get queries from integrators
> that have previously stored serial numbers in a big integer field. After
> the "recent"  cert library updates which now properly produce 64 bit
> positive integers like the CAB forum requires, they ran into plenty of
> problems with the first certificate serial that was larger than 2^63.
>
> Map that to Django and I think changing to PositiveBigIntegerField is a
> fair workaround. Not sure if it is worth changing the default, but the
> requirements do exist for some people.
>
> Cheers,
> Florian
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/2a5a9a02-70d6-4f77-9af0-c9217cb9eb3an%40googlegroups.com
> 
> .
>


-- 
Adam

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM0vpmOPMsN%3DMJekEJYDaGwB9NpRKUmocAfHuO18ZN2U%2Bg%40mail.gmail.com.

Re: GSOC Proposal : Adding a Redis cache backend to Core

[charettes]

Hello Daniyal,

> I want to move ahead with using the pickle module. However, does it 
seem necessary to add support for other serializers ( json / yaml / msgpack 
) as well?

I don't think that adding support for configurable serialization is 
necessary for this project. Don't get me wrong, I think it'd be great if 
cache backends allowed for their serialization to be configured but I think 
it's out of scope for this project as no other core backends do so.

Cheers,
Simon

Le mercredi 7 avril 2021 à 18:04:10 UTC-4, abbasi.d...@gmail.com a écrit :

> Hi
> Since redis does not support complex objects, we need to serialize the 
> data into a suitable format. Most third-party libraries use either the 
> pickle module, to serialize the values or use json / yaml serializers. I 
> want to move ahead with using the pickle module. However, does it 
> seem necessary to add support for other serializers ( json / yaml / msgpack 
> ) as well?
>
> Regards,
> Daniyal Abbasi
>
>
> On Thu, Apr 1, 2021 at 4:16 AM Daniyal Abbasi  
> wrote:
>
>> Hey
>> I am an aspirant  for GSOC 2021. I was really interested in the project 
>> "Adding a Redis cache backend to Core" as I myself have used third party 
>> libraries to integrate redis as a caching backend. A link to by draft 
>> proposal can be found here 
>> .
>>  
>> I have shared this draft proposal to the gsoc dashboard too.
>>
>> Regards,
>> Daniyal Abbasi
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/d0c23af8-e34c-46d4-9b4d-c84e050b00c6n%40googlegroups.com.