Hi Ruwan,
Thanks for the clarification and I think the approach works according to
the requirements.

@Wathsara, also, I would like to add a couple of more suggestions for the
architecture here,

1. According to the shared diagram, language server process runs remotely
and connects via WS. I think the language server process also should run
locally along with the VSCode process. This is the most commonly used
pattern and would be efficient.
2. If we get the language server process to the client-side, then we can
implement caching layers at the language server level and this would cut
down a significant amount of server calls as well.
3. We can use the STDIO launcher to launch the language server process and
communicate via the standard I/O.
4. As per Ruwan's explanation, we might not need to access IS instance per
each language server request if we have the LS process also locally.

Cheers,

On Mon, Oct 14, 2019 at 3:25 PM Ruwan Abeykoon <ruw...@wso2.com> wrote:

> Hi Nadeeshan,
> Stdio is a good idea, however, IAM story is that we need to run "Product
> IS" in developer mode to get the language server going. Each hint,
> highlighting , etc, are dependent on some other artifacts already
> configured in IS, e.g. "Identity Provider", "Claim Mapping"
> Hence it is imperative to connect to running IS to get proper context
> information.
>
> BTW, We might want to add different remote protocols as WS is sometimes
> blocked by firewalls.
>
> Cheers,
> Ruwan A
>
>
>
> On Mon, Oct 14, 2019 at 3:16 PM Nadeeshaan Gunasinghe <nadeesh...@wso2.com>
> wrote:
>
>> Hi Wathsara,
>>
>> Just a small suggestion, as per the architecture you are having only one
>> launcher (web socket launcher). What if we have an STDIO Launcher
>> implementation as well (If it is a valid use-case) and the user can use the
>> stdio launcher when using the plugin locally?
>>
>> Cheers,
>>
>> On Mon, Oct 14, 2019 at 3:06 PM Wathsara Daluwatta <waths...@wso2.com>
>> wrote:
>>
>>> Hi all,
>>>
>>> We have started to implement the Language server support for Identity
>>> Server. This will enhance the developer's experiences of IAM artifacts like
>>> service providers. It will help Dev, QA, to design and see the artifacts
>>> easily. Initially, we are building a VScode extension that is going to
>>> support the adaptive authentication scripts of the WSO2 identity server.
>>>
>>> A language server for adaptive authentication scripts is been
>>> implemented in Java (Server-side). Then the language server and the vscode
>>> plugin will be communicated via WebSocket.
>>> The reason why we selected the WebSocket is to connect the IDE (vscode)
>>> with the IAM server, local, on-prem, in a remote server or in the cloud.
>>>
>>> I have attached the high-level architecture as well.
>>>
>>>    Wathsara Daluwatta | Intern - Engineering | WSO2 Inc.
>>>
>>>   (m) +94717005121 | Email : waths...@wso2.com <sheh...@wso2.com>
>>>
>>> [image: https://wso2.com/signature] <https://wso2.com/signature>
>>>
>>>
>>
>> --
>> *Nadeeshaan Gunasinghe*
>> Associate Technical Lead | WSO2 Inc.
>>
>> mobile:  +94770596754
>> email:    nadeesh...@wso2.com
>> in:          https://www.linkedin.com/in/nadeeshaan
>>
>>
>
> --
> Ruwan Abeykoon | Director/Architect | WSO2 Inc.
> (w) +947435800  | Email: ruw...@wso2.com
>
>

-- 
*Nadeeshaan Gunasinghe*
Associate Technical Lead | WSO2 Inc.

mobile:  +94770596754
email:    nadeesh...@wso2.com
in:          https://www.linkedin.com/in/nadeeshaan
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to