[Architecture] Common Terms Registry

Evgeni Tsakov etsakov at asteasolutions.com
Wed Jan 30 06:49:36 EST 2013


Hi Yura,

A couple of updates to the registry - tell me what you think :)
https://github.com/tsakov/common-terms-registry

Rock On,
Evgeni


On Tue, Jan 29, 2013 at 6:27 PM, Evgeni Tsakov
<etsakov at asteasolutions.com>wrote:

> Hi Yura,
>
> I forgot to include the architecture list in my previous email but it can
> be seen in this one.
>
> I see what you mean now. The way I imagined it is that the user visits
> ".../common/fontSize" without an extension. Then the registry component
> receives the relevant .json file and transforms it to nice html, eventually
> stacking many common terms in one page as the result of a query.
>
> If the user wants the json format of a single common term they can visit
> something like ".../common/fontSize.json"
> I think our ideas aren't very different :)
>
> Rock On,
> Evgeni
>
>
>
> On Tue, Jan 29, 2013 at 5:05 PM, Yura Zenevich <yura.zenevich at gmail.com>wrote:
>
>> Hi Evgeni,
>>
>> Sorry I was confusing there :).
>>
>> What I meant was that common terms registry, from what I understand, will
>> be one of those components (node apps) that will be accessed by both: other
>> components as well as users.
>>
>> So in case other components access it (for example match maker for
>> whatever reason), they would just do what we usually do, e.g. query, and
>> get some json back that they will consume.
>>
>> In case of a user accessing a REGISTRY (because they want some details
>> about the terms or anything else), chances are they would want to do that
>> through the browser and instead of json they would want an html output.
>>
>> What that means to us is that the common terms registry API would need to
>> support multiple formats that it outputs its data in (again using RESTful
>> approach). So for example you can think of the REGISTRY supporting these
>> urls as part of its API:
>>
>> ../common/fontSize[.json]
>> ../common/fontSize[.html]
>>
>> or something of that nature.
>>
>> Let me know what you think!
>>
>> Yura
>>
>> On 2013-01-29, at 9:06 AM, Evgeni Tsakov <etsakov at asteasolutions.com>
>> wrote:
>>
>> Hi Yura,
>>
>> Quoting:
>>
>>> Perhaps one of the things to keep in mind is the fact that we will
>>> support different formats to represent data from the REGISTRY (e.g. .json,
>>> .html etc). Perhaps you might start thinking about supporting that
>>> additional/optional url parameter within the url.
>>>
>>
>> I don't think I understand well enough what you mean. Can you be more
>> specific about that "optional url parameter"? There should be some way to
>> structure queries, but I am not sure if the ways the solutions registry
>> does it will be the best here. Perhaps we should discuss it tomorrow if
>> you're not busy. Maybe before the architecture call?
>>
>> Rock On,
>> Evgeni
>>
>>
>> On Mon, Jan 21, 2013 at 11:14 PM, Yura Zenevich <yura.zenevich at gmail.com>wrote:
>>
>>> Hi Evgeni,
>>>
>>> I just had a chance to take a look at the repo and it looks really good.
>>> Overall the structure of the REGISTRY component is exactly what was
>>> intended. Perhaps one of the things to keep in mind is the fact that we
>>> will support different formats to represent data from the REGISTRY (e.g.
>>> .json, .html etc). Perhaps you might start thinking about supporting that
>>> additional/optional url parameter within the url.
>>>
>>> We are currently working on a new gpii.renderer grade that will let you
>>> render html on the server side quite easily.
>>>
>>> One general suggestion I have is to perhaps instead of keeping all of
>>> the code as a separate repo, you should just make a branch of
>>> GPII/universal and put all of the REGISTRY related code into
>>> gpii/node_modules/registry. You'll then find it unnecessary to write things
>>> like start.js and extra configuration all over again. Also, given that it
>>> will probably end up in universal it would be much easier to review and
>>> merge your contribution down the road.
>>>
>>> Regards,
>>>
>>> Yura
>>>
>>>
>>>
>>>
>>> On 2013-01-21, at 5:40 AM, Evgeni Tsakov <etsakov at asteasolutions.com>
>>> wrote:
>>>
>>> Hi Yura,
>>>
>>> Have you had a chance to look at my github repository<https://github.com/tsakov/common-terms-registry>?
>>> Just tell me if it's what you expected it to be, and feel free to
>>> criticize. Also, what do you think should the next steps be?
>>>
>>> Rock On,
>>> Evgeni
>>>
>>>
>>> *The information in this e-mail and any accompanying files is intended
>>> only for the recipients named above. This message may contain CONFIDENTIAL
>>> INFORMATION THAT IS LEGALLY PRIVILEGED. If you are not an intended
>>> recipient, you may not download, copy, disseminate, distribute or use in
>>> any way the information in this e-mail. Any of these actions can be a
>>> criminal offense. If you have received this e-mail in error, please notify Astea
>>> Solutions AD immediately by reply e-mail, and delete this e-mail and
>>> any copies of it.*
>>>
>>>
>>>
>>
>> *The information in this e-mail and any accompanying files is intended
>> only for the recipients named above. This message may contain CONFIDENTIAL
>> INFORMATION THAT IS LEGALLY PRIVILEGED. If you are not an intended
>> recipient, you may not download, copy, disseminate, distribute or use in
>> any way the information in this e-mail. Any of these actions can be a
>> criminal offense. If you have received this e-mail in error, please notify Astea
>> Solutions AD immediately by reply e-mail, and delete this e-mail and any
>> copies of it.*
>>
>>
>>
>

-- 
*The information in this e-mail and any accompanying files is intended only 
for the recipients named above. This message may contain CONFIDENTIAL 
INFORMATION THAT IS LEGALLY PRIVILEGED. If you are not an intended 
recipient, you may not download, copy, disseminate, distribute or use in 
any way the information in this e-mail. Any of these actions can be a 
criminal offense. If you have received this e-mail in error, please notify Astea 
Solutions AD immediately by reply e-mail, and delete this e-mail and any 
copies of it.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gpii.net/pipermail/architecture/attachments/20130130/71a1d44c/attachment-0001.html>


More information about the Architecture mailing list